<html><head></head><body>
<p>Hi Shaping,</p>
<p>Thank you for the helpful response and your taking the time to
compose it. I am thinking there are two statements you are making:
1) you require sub 10 ms GC times and 2) the use of static typing
regarding ref-cap states, allows you to present a proxy type
reflecting the correct protocol for the subject farRef and static
type all interactions with it.<br/>
<br/>
1) is interesting.<br/>
2) In Raven, any message may be sent, passed as a string in a
DeliveryMessage & DeliveryOnlyMessage. The transition of ERefs
is well defined (NearERef -> PromiseERef -> a new
Near/FarERef); (RemotePromiseERef -> FarERef -> a new
RemotePromiseERef -> a new Near/FarERef).</p>
<p>The issue is how would a user/developer know that the subject
farRef they are holding understands any of a particular protocol.
The need to limit some protocol by failing to provide their
capabilities is solved by a securityProxy, specific for each
exported class, that provides only he allowed protocol. We do not
need nor find valuable any static typing done by the compiler.
Let's stay dynamic and allow runTime detection of failed protocol
use, so we can use testing to validate the state machine. Static
Typing is a false security blanket, Unit Testing is King!<br/>
</p>
<div class="moz-cite-prefix">On 5/8/20 1:06 AM, Shaping wrote:<br/>
</div>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)"/>
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle29
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">How
do Pharo’s and Squeak’s VMs differ? I thought
OpenSmalltalkVM was the common VM. I also read something
recently from Eliot that seemed to indicate a fork. </span><o:p></o:p></p>
<p style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
thought Pharo had the new tools, like GT, but I’m not sure.
I don’t follow Squeak anymore. </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Pharo may, it is
fast moving and they drop historical support as new tools come
online. I don't follow Pharo anymore. There is a common VM but
the builds are separate.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
mostly don’t follow Squeak, but do follow Pharo on and off,
and may port as soon as the GUI formatting problems are
fixed or are fixable by my own use of Spec2. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
tried Squeak 5.3 a few days ago for the first time in 16
years. It has a nicer induction/setup process, but menus
were malfunctioning (rending spastically) before I finished
getting reacquainted with the new surface. I don’t have
time these days to finish playing with it. I may get back
to it, but why do that if the Pharo GUI is more advanced?
Besides avoiding Pharo framework bloat and confusion, what
about Squeak compels you to use it instead of Pharo for VM
dev?</span></p>
</div>
</blockquote>
<p>What can I say? It is home.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p><a href="https://ponylang.zulipchat.com/#narrow/search/lzip" moz-do-not-send="true">https://ponylang.zulipchat.com/#narrow/search/lzip</a></span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Here was the
thread reference I was unable to follow. That you provided it
around a discussion of why the CogVM was "not acceptable". Say
what? So we are adding a near real-time requirement? I would
suggest that the CogVM meets near real-time requirements. The
longest GC pause may be 100 ms let us say. That is still near
real-time.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">5
to 10 ms is what I need. Even Pony’s GCing barely keeps up
with this, but the effect is smoother because all actors are
running all the time, except when each actor GCs its own
little heap. The timing issue is more about smoothness and
predictably small tail latencies at the <u>right end of a
very steep and narrow latencies distribution</u>. <br/>
</span></p>
</div>
</blockquote>
<p>Yes, indeed. I can see this would be valuable and I support this
for the CogVM of some flavor. This dispersed cost can yield much
finer resolutions. Alas, above my pay grade, Captain.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Read
the thread above and watch the video to sharper your
imagination and mental model, somewhat, for <u>how real
object-oriented programs work <b>at run-time</b>.</u>
The video details are fuzzy, but you can get a good feel
for message flow. </span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">Exactly the way
Smalltalk operates at runtime. Smalltalk was made with the
benefit that the core message passing paradigm is the exact
model of interaction we see remotely: message passing. Squeak
is a native message passing machine.<br/>
<br/>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">This
should have happened first in Smalltalk. </span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">It did.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">No,
the <b>idea</b> of asynchronous messaging did, but not the
implementation. We’re not discussing the same phenomenon.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Smalltalk
does not in general have asynchronous messaging between all
actors all the time. It doesn’t even have actors by default
in the core language. You have to design them as an
afterthought. That’s just wrong.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Smalltalk
does not have true actors as a baseline implementation of
the OO programming paradigm. You have to engineer it if you
want it, and it doesn’t scale well with the green threads.
Just non-blocking FFI doesn’t count; that is necessary and
good, but not sufficient.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Async
messaging: that was the original vision, and it still works
best for state-machine construction, because no blocking and
no read/write-barriers are needed. Here’s the gist, and
you’ll find that Kay says the same in his talks, repeatedly
(apparently no one listens and thinks about using it): <u>advance
the state of the state-machine only by exchange of
asynchronous messages between actors. </u> That’s the
whole thing. Then you have the tooling on top of that to
make the SM building systematic, reliable, and pleasant.
That’s missing too, and must be done, as well, or the core
idea is hard to use fully—which is largely why we program as
we do today. Most programmers are old dogs coding in the
same old wrong way, because the new way, which is very much
better, is even harder to do without the right tools and
guarantees, and we don’t have those yet. Functional
programming (great for many domains) is a much better choice
for general-purpose programming than the actor model <u>with
the current actor-based tools.</u> <o:p></o:p></span></p>
<p class="MsoNormal"><br/>
<br/>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">The
performance of the GC in the CogVM is demonstrated with
this profiling result running all Cryptography tests. Load
Cryptography with this script, open the Test Runner select
Cryptography tests and click 'Run Profiled':<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:1.0in">Installer
ss<br/>
project: 'Cryptography';<br/>
install: 'ProCrypto-1-1-1';<br/>
install: 'ProCryptoTests-1-1-1'.<o:p></o:p></p>
</blockquote>
<p style="margin-left:1.0in">Here are the profiling results.<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:1.0in"> - 12467
tallies, 12696 msec.<br/>
<br/>
**Leaves**<br/>
13.8% {1752ms} RGSixtyFourBitRegister64>>loadFrom:<br/>
8.7% {1099ms} RGSixtyFourBitRegister64>>bitXor:<br/>
7.2% {911ms} RGSixtyFourBitRegister64>>+=<br/>
6.0% {763ms} SHA256Inlined64>>processBuffer<br/>
5.9% {751ms} RGThirtyTwoBitRegister64>>loadFrom:<br/>
4.2% {535ms} RGThirtyTwoBitRegister64>>+=<br/>
3.9% {496ms} Random>>nextBytes:into:startingAt:<br/>
3.5% {450ms} RGThirtyTwoBitRegister64>>bitXor:<br/>
3.4% {429ms}
LargePositiveInteger(Integer)>>bitShift:<br/>
3.3% {413ms} []
SystemProgressMorph(Morph)>>updateDropShadowCache<br/>
3.0% {382ms}
RGSixtyFourBitRegister64>>leftRotateBy:<br/>
2.2% {280ms}
RGThirtyTwoBitRegister64>>leftRotateBy:<br/>
1.6% {201ms} Random>>generateStates<br/>
1.5% {188ms} SHA512p256(SHA512)>>processBuffer<br/>
1.5% {184ms} SHA256Test(TestCase)>>timeout:after:<br/>
1.4% {179ms} SHA1Inlined64>>processBuffer<br/>
1.4% {173ms} RGSixtyFourBitRegister64>>bitAnd:<br/>
<br/>
**Memory**<br/>
old -16,777,216 bytes<br/>
young +18,039,800 bytes<br/>
used +1,262,584 bytes<br/>
free -18,039,800 bytes<br/>
<br/>
**GCs**<br/>
full 1 totalling 86 ms (0.68% uptime),
avg 86 ms<br/>
incr 307 totalling 81 ms (0.6% uptime),
avg 0.3 ms<br/>
tenures 7,249 (avg 0 GCs/tenure)<br/>
root table 0 overflows<o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-left:1.0in">As shown, 1
full GC occurred in 86 ms<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Not
acceptable. Too long.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">What is your near
real-time requirement?<br/>
<br/>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">5
to 10 ms pauses per actor, not globally whilst all actors
wait. Think <i>smooth.<o:p></o:p></i></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span>and
307 incremental GCs occurred for a total of 81 ms. All of
this GC activity occurred within a profile run lasting
12.7 seconds. The total GC time is just 1.31% of the total
time. Very fast.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Not
acceptable. Too long. And, worse, it won’t scale.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">I am unaware of
any scaling problems. In Networking, 1000s of concurrent
connections are supported. In computations, 10,000s objects.
What are your timing requirements? Each incremental took a
fraction of a millisecond to compute: <b>264 microseconds.</b><br/>
<br/>
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> The
problem is not the percentage; it’s the <u>big delays
amidst other domain-specific computation.</u> These
times must be much smaller and spread out across many
pauses during domain-specific computations.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">See the 307
incremental GCs? These are 264 microsecond delays spread out
across <span style="font-size:11.0pt;font-family:"Calibri",sans-serif">domain-specific
computations.</span> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We
have to watch definitions and constraints carefully. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Where
memory management is concerned, this thread tries to compare
the merits of the two extremes: per-actor memory
management, as in the Orca (Pony practically), and global
stop-the-world (StW) collection as in a classical
Smalltalk. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">You
seem to be presenting something intermediate above, where
there are segments that are GCed in turn. Are you stopping
all domain threads/messaging during the incremental GCs, or
just the ones for objects in a certain section of the heap?
Or, are the heap partitions divided by more traditional
criteria, like object size and lifespan? What is the
spacing between the incremental GCs? <span style="color:#00B0F0">Steady frequency of pauses,
smallness of pauses, and <u>narrowness of distribution of
longest pauses</u>, especially, are the most important
criteria. <o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
No serious real-time apps can be made in this case.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">Of course they
can. Model the domain as resilient & accepting of 100 ms
pauses, for full GCs. It may be more could be done to the
CogVM for near real-time, I am not very knowledgeable about
the VM.<br/>
<br/>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We
are discussing different app domains.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
can’t use 100 ms pauses in my real-time app. I need sub 10
ms pauses. Again even Pony needs better GCing, but the
report I have from Rocco shows more or less acceptable
pauses. He was kind enough to run the program again with
the GC stats turned on. I’ll try to find the document and
attach it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
suggest studying the Pony and Orca material, if the
video and accompanying explanation don’t clarify
Pony-Orca speed and scale. </span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">Yeah, the video
did not suggest anything other than using message passing. <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">You
can’t miss this detail; it’s almost everything that
matters: <b><u>asynchronous</u></b><u> message passing
between all actors, all the time, on the metal, not as an
afterthought, with a guarantee of no data-races.</u><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">I could not find
the thread discussing GC. Would you please post the specific
URL to get to that resource, please? I do not want to guess
any longer.<br/>
<br/>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
don’t get it. It works for me in a newly opened tab. I
don’t know what the problem is. Zulip should work for you
as it does for me. Login to your Zulip and search on
‘Rocco’. You’ll see Rocco’s stuff, which is largely about
the parsing app he has. Better, just ask for the info you
want. <br/>
</span></p>
</div>
</blockquote>
<p>I have found several documents. One has over a 100 pages! On GC.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Why
would the idea of ‘remote’ enter here? The execution
scope is an OS process. Pony actors run on their
respective threads in one OS process. Message passing
is zero-copy; all “passing” is done by reference. No
data is actually copied.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">In the SqueakELib
Capabilities model, between Vats (in-process, inter-process
& inter-machine-node) most references to Actors are remote
and then we have zero-copy. Sometimes we need to pass
numbers/strings/collections and those are pass-by-copy.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Yeah,
the copying won’t work well. Just never do it, at least not
in one OS process. 0-copy messaging is the rule in Pony.
Even this may not matter much eventually. The MM is being
reworked with the hope of eliminating all consensus-driven
messaging, which can be expensive, even if only transiently,
on highly mutable object sets. See the Verona project,
which seems to be slowly converging with Pony: <a href="https://github.com/microsoft/verona/blob/master/docs/faq.md" moz-do-not-send="true">https://github.com/microsoft/verona/blob/master/docs/faq.md</a>.
The Orca memory management core-weakness is still the fact
that all messaging must be traced so that the collector
knows which actors still refer to a given object. This is
true of all concurrent collectors. That problem—and it’s a
big problem-- goes away completely if the Pony runtime
becomes Verona-ized.</span></p>
</div>
</blockquote>
<p>My hope is that this is interesting to those more knowledgeable
of Squeak's(Pharo's) VM.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
The scheduler interleaves all threads needing to share a
core if there are more actors than cores. Switching
time for actor threads, in that case, is 5 to 15 ns.
This was mentioned before. Opportunistic work stealing
happens. That means that all the cores stay as busy as
possible if there is any work at all left to do. All of
this happens by design without intervention or thought
from the programmer. You can read about this in the
links given earlier. I suggest we copy the design for
Smalltalk.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">Which specific
links? Could you send a summary email?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Not
now, maybe later. </span></p>
</div>
</blockquote>
<p>Very well, as you find your time. I appreciate you.</p>
<p>I believe the same is true of the Local/Remote Capabilities of
#CapabilitiesLocal and #Raven. The entire mechanism of #sending
messages, rather than #calling them enables 0-copy (an app design
choice!) with enough Vats running to use the cores, They are not
usually multiple Vats in one process, they are in separate
processes. Therefore, the interaction of messages between Vats are
remote, through a socket. I suppose a SharedMemoryThunk could be
designed. All of this is automatic.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Some
of this data comes from lectures by Clebsch, but you’ll find
most of the meat in the Pony papers, for which links can be
found on the community page: <a href="https://www.ponylang.io/community/" moz-do-not-send="true">https://www.ponylang.io/community/</a>
. <br/>
</span></p>
</div>
</blockquote>
<p>I found some material to read, thank you.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
think the Pony runtime is still creating by default
just one OS process per app and as many threads as
needed, with each actor having only one thread of
execution by definition of what an actor is
(single-threaded, very simple, very small). A
scheduler keeps all cores busy, running and
interleaving all the current actor threads. Message
tracing maintains ref counts. A cycle-detector keep
things tidy. Do Squeak and Pharo have those
abilities?</span><o:p></o:p></p>
</blockquote>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">In the case of
remote capability references, there is reference counting.
This occurs inside the Scope object, there are 6 tables: 2 for
third party introduction (gift tables), 2 for outgoing
references (#answers & #export) and 2 for incoming
references (#questions & #imports). These tables manage
all the remote reference counting. Once again between any two
Vats (in-process, inter-process & inter-machine-node).
There are 2 GC messages sent back from a remote node (GCAnswer
& GCExport) for each of the outgoing references. Alice has
a reference to a remote object in Bob, when the internal
references to Alice's reference end and the RemoteERef is to
be garbage collected a GC message is sent to the hosting Vat,
Bob.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">In
Squeak/Pharo do all actors stop for the GCs, even for the
smaller incremental ones?</span></p>
</div>
</blockquote>
<p>I suppose my answer to you is yes, to the best of my knowledge.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p style="margin-left:.5in">I have some experience with
state-machine construction to implement security protocols. In
Squeak, DoIt to this script to load Crypto and ParrotTalk
& SSL (currently broken) and see some state-machines:<o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">Installer
ss<br/>
project: 'Cryptography'; install: 'ProCrypto-1-1-1';<br/>
project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';<br/>
project: 'Cryptography'; install: 'CapabilitiesLocal';<br/>
project: 'Oceanside'; install: 'ston-config-map';<br/>
project: 'Cryptography'; install: 'SSLLoader;<br/>
project: 'Cryptography'; install: 'Raven'.<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Pony
has Actors. It also has Classes. The actors have
behaviours. Think of these as async methods. <u>Smalltalk
would need new syntax for Actors, behaviours, and the
ref-caps that type the objects.</u> Doing this last
bit well is the task that concerns me most.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">Which? "ref-caps
that type the objects"? What does that mean?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">This
is the best page on ref-caps: <a href="https://www.ponylang.io/learn/#reference-capabilities" moz-do-not-send="true">https://www.ponylang.io/learn/#reference-capabilities</a></span></p>
</div>
</blockquote>
<p>This was the material I found to read! Thank you.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p><br/>
</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
six ref caps define which objects can mutate which others at
compile time. Ref-caps provide the guarantees. The ref
caps connect the code of your language (Pony so far) to the
MM runtime at compile time.</span></p>
</div>
</blockquote>
<p>This is static typing, unrelated to GC timing requirements. Use
of a dynamic implementation of Promise capabilities and the state
machine the references themselves undergo, is perfectly fine.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"> With the
CapabilitiesLocal I pointed you to, we have an Actor model
with async message passing to behaviors of an Actor. Squeak
has Actors supporting remote references (3-way introductions,
through the gift tables is broken. Remote references from
Alice to Bob is working. See the tests in ThunkHelloWorldTest:
#testConnectAES, #testConnectAESBufferOrdering &
#testConnectAESBuffered.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">that exists
for Smalltalk capabilities and Pony capabilities. In fact,
instead of talking about actors, concurrency &
parallel applications, I prefer to speak of a capabilities
model, inherently on an event loop which is the foal point
for safe concurrency.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
suggest a study of the Pony scheduler. There are
actors, mailboxes, message queues, and the scheduler,
mainly. You don’t need to be concerned about safety.
It’s been handled for you by the runtime and ref-caps.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">Same with Raven,
plus remote. We have all of that. See the PriorityVat class.</p>
</div>
</blockquote>
<p>Here is my model of what a Vat looks like. The Vat has a green
thread (called Process) that runs all sends and calls. A Vat has a
current stack, for calling methods, a message queue for sending
messages async, in priority-sorted FIFO order (scheduling), and a
Pool of event-loop semaphores waited upon for continuations (to be
built)(scheduling). All interactions with Actors managed by that
Vat must come through the Queue, processed by the vatProcess. No
Actor an be reached by more than one Vat. No mailboxes, yet. Need
published public keys under an identity so they can be encrypted.<br/>
</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in"><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Last
time I checked, Squeak/Pharo didn’t have actors that run
without interruption by the GC. Or can Smalltalk actors do
that now? How hard to implement on OSVM would a per-actor
memory architecture be? You need a concurrent collector
algo to make it work. I don’t think you have that in the
current VM. </span></p>
</div>
</blockquote>
<p>I do not know, myself, but this is a separate issue than static
typing ref-caps.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
don’t have time for Pony programming these days--I can’t
even read about these days. Go ahead if you wish.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Your
time is better spent in other ways, though.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p style="margin-left:.5in">I communicate with you about what
could be, but I agree I must stay focused on my primary
target, which is porting SSL to use my new ThunkStack
framework for remote encrypted communications. End-to-end
encryption is what I am about. Here is a visualization of what
I aim for with TLS 1.3 and Signal as to be done projects, it
is currently vaporware. I have ParrotTalk done and am working
SSL, then I will move to SSH. The script I listed above will
load all remote packages, except for SSH. I m attaching the
flyer I created to broadcast Squeak's ProCrypto configuration.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><img id="_x0000_i1025" src="cid:part5.D442641D.4AF73197@pm.me" class="" width="611" height="543" border="0"/><o:p></o:p></p>
<p style="margin-left:.5in"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
speed and scale advantages of Orca over the big-heap
approach have been demonstrated. That was done some
time ago. Read the paper by Clebsch and friends for
details. </span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">Regarding
capabilities please read the ELib documentation on ERights
website: <a href="http://erights.org/elib/index.html" moz-do-not-send="true">http://erights.org/elib/index.html</a><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
material is not well organized, and is very hard to even
want to read. Maybe you are the one to change that.</span></p>
</div>
</blockquote>
<p>I can't change that, but I found them to be very informative for
my purposes, which was to replicate this design in Squeak. See
Raven. I have all the same classes and a few new ones (see
Scope). I have read over & read over & read over that
documentation I referenced, for ELib, many, many times, over the
years: 16 years now I have worked on SqueakELib).</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p><br/>
</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I’m
looking for: 1) definitions of all terms that are new or
nonstandard; 2) problem-constraint invariants (one can’t
reason about anything without invariants); 3)
problem-solution objectives expressed in<u> measurable
terms, like data-rate or latency</u>. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Can
I get those? This might be a good time and place to
describe your proposed concurrency solution for Smalltalk in
terse, measurable terms. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Have
you measured a running actor-based app on one node? On two
or more?<o:p></o:p></span></p>
<p class="MsoNormal"><br/>
<br/>
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">You state that
Pony is just to access Orca. <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
two are codesigned.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">What makes Orca so
great?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
measurements. Read the end of the Orca paper if you can’t
read the whole thing. Orca is the best concurrent MM
protocol now. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Aside:
I want to be rid of general purpose GC. I think the purely
functional approach with persistent data structures can work
better (think Haskell). You still need to maintain state in
processing queues (think Clojure; not sure how Haskell
handles this). You still need temporal-coherency control
devices at the periphery for IO (atoms for example). <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">There are
definitely more than one Actor per Vat. <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Why
have another construct? It appears to be scoped to the
node. Is that the reason for the vat’s existence? Does it
control machine-node-specific messaging and resource
management for the actors in it contains?</span></p>
</div>
</blockquote>
<p>That's right, it is the stack, queue & pool for establishing
a single threaded event-loop.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in">1 per process.
There will be a finite number of Capability actors in each
event loop. <o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">But more than one
and scale into thousands per Vat.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Is
there a formal definition of <i>vat</i>? I found this:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal">“A vat is the part of the Neocosm
implementation that has a unique network identity. We expect
that normal circumstances, there will only be one vat running
on a particular machine at one time. Neocom currently (28 May
1998) supports only one avatar per vat.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p style="margin-left:.5in">Here is the state machine
specification for ParrotTalk version 3.7, which is compiled by
the ProtocolStateCompiler. This stateMap models states,
triggers, transitions, default and callbacks and is simple to
use.<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p style="margin-left:.5in">ParrotTalkSessionOperations_V3_7
class>>#stateMap<o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
"(((ParrotTalkSessionOperations_v3_7 stateMap compile)))"<br/>
<br/>
| desc |<br/>
desc := ProtocolStateCompiler initialState: #initial.<br/>
(desc newState: #initial -> (#processInvalidRequest:
-> #dead))<br/>
add: #answer -> (nil ->
#receivingExpectHello);<br/>
add: #call -> (nil ->
#receivingExpectResponse).<br/>
(desc newState: #connected ->
(#processInvalidRequest: -> #dead))<br/>
addInteger: 7 -> (#processBytes: ->
#connected).<br/>
(desc newState: #dead -> (#processInvalidRequest:
-> #dead)).<br/>
<br/>
(desc newState: #receivingExpectHello ->
(#processInvalidRequest: -> #dead))<br/>
addInteger: 16 -> (#processHello: ->
#receivingExpectSignature).<br/>
(desc newState: #receivingExpectSignature ->
(#processInvalidRequest: -> #dead))<br/>
addInteger: 18 -> (#processSignature: ->
#connected);<br/>
addInteger: 14 -> (#processDuplicateConnection:
-> #dead);<br/>
addInteger: 15 -> (#processNotMe: -> #dead).<br/>
<br/>
(desc newState: #receivingExpectResponse ->
(#processInvalidRequest: -> #dead))<br/>
addInteger: 17 -> (#processResponse: ->
#connected);<br/>
addInteger: 14 -> (#processDuplicateConnection:
-> #dead);<br/>
addInteger: 15 -> (#processNotMe: -> #dead).<br/>
^desc.<o:p></o:p></p>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</blockquote>
</blockquote>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">--Because
it will continue the current Smalltalk-concurrency lameness.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">The only
identified difference is not the Actor model, it is the near
real-time requirements on the Garbage Collector, yes? So what
lameness do you reference?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
actor model is a problem too if you stop all actors with a
StW GC. Fix the problem by letting each actor run until it
finishes processing the last message. Then let it collect
its own garbage. Then let it take the next message from the
queue. All actors are single-threaded by definition. This
maximizes processing rate and smoothness of GC-disruption of
domain work. It also increases tracing overhead transiently
when large numbers of mutable objects are used (21% peak CPU
consumption ascribable to tracing when you throw the
tree/ring exercise at Pony with as many mutable types as
possible). We will be turning to functional programming
strategies for at least some (if not eventually all) core
(not peripheral IO) parallelization efforts, but I digress
somewhat.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Two
big problems impede parallelization of programs in
Smalltalk: 1) the GC stops all actors, all of them or large
chunks of them at once, depending on how the GC works.
Neither situation is acceptable. That this pause is small
is not as important as the work lost from all the actors
during that period; 2) core Smalltalk doesn’t have a
guaranteed concurrency-integrity model that automatically
starts threads on different cores; it can only interleave
them on one core (green threading). <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">These
ideas should not be add-ons or frameworks. They should be
core features. If we can do the above two in Squeak/Pharo,
I’ll use Squeak/Pharo to work on a VM. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">Have you tried
implementing SmallInteger class>>#tinyBenchmarks in
Pony?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">No,
sadly. I’ve yet to build Pony. I’m still reading about the
techniques and background. I plan to parse large CSV files
into objects, as in Rocco’s exercise. I have some files I
can use for that purpose, and can get the same data over
HTTP to test a connection too. That would be a nice first
experiment. We need to be clinical about this. All the
talk and hand-waving is an okay start, but at some point, we
must measure and keep on doing that in a loop, as
architecture is tweaked. I would like to compare a Pony
parsing program to my VW parsing program as a start. But
the Pony work has to wait.</span></p>
</div>
</blockquote>
<p>What are you saying, you don't code?</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Too
slow/wasteful. Moving an actor isn’t needed if the
each has its own heap.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">In ELib, why not
allow an Actor to be mobile and move from Alice's Vat to Bob's
Vat?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Are
Vats for scoping actors to specific machine nodes? If so,
then yes move the actors to another machine node if it is
better suited to what the actor does and needs. </span></p>
</div>
</blockquote>
<p>Right.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"> Then automated
management apps can really truly rebalance Actors. Only on a
rare moment, not for every call.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Yes,
we must have run-time feedback to adjust resources, which
are the actors and the machine nodes they are made to run
on. A coordination actor would watch all other actors and
clusters of them.<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><br/>
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">Once again the
near real-time of the Orca Garbage Collector. I am not
convinced, but reading some papers. <br/>
<br/>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Runtime
action with an Orca collector is definitely smoother. This
we can know before the fact (before we measure) from the
fine-grain MM. What is not clear without testing is overall
speed. We need to test and measure.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">86 ms will not
break the contract, I propose.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It’s
okay for a business app, certainly--not such much for
machine-control or 3D graphics. It’s good enough for
prototyping a 3D sim, but not for deployment. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><br/>
<br/>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Yes,
and a dedicated cycle-detecting actor watches for this
in Pony-Orca. </span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">I don't watch for
it, but it is a strong design consideration. Keep Actor
behaviors short and sweet.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
cycles are about chaining of messages/dependencies between
actors. When a programmer makes these actor clusters
manually, messing up is easy. A higher-level tools is need
to manage these constructions. The actor-cycles will exist
and become problematic even if each actor is fast. The
detector finds and exposes them to the programmer. <o:p></o:p></span></p>
<p class="MsoNormal"><br/>
<br/>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">E-right's
event loops ensure no data races, as long as actor objects
are not accessible from more than one event-loop.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Speed
hit.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">???<br/>
<br/>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">This
constraint is not needed to guarantee correct concurrency in
Pony, which happens at compile time and takes no CPU
cycles. The approach above sounds dynamic; there are some
CPU cycles involved.<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Yes;
I didn’t claim otherwise. The networked version is
coming. See above. My point is that the ‘remote’
characterization is not needed. It’s not helping us
describe and understand. </span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">It does so for me,
either we have inner-Vat message calling, immediate, adding to
the stack. And we have inter-Vat message sending,
asynchronous, adding to the queue.<br/>
<br/>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
still don’t see a clear definition of <i>vat.</i><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">None
of the above language is needed when the concurrency scheme
is simpler and doesn’t use those ideas and devices. <o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in">Design wise,
it makes much sense to treat inter-thread, inter-process
and inter-machine concurrency as the same remote
interface.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
design is already done, modulo the not-yet-present 3-way
gift giving network extension. Interfacing between
actors is always by async messaging, even local sends to
nearRefs. Messaging will work as transparently as
possible in the networked version across machine nodes.
</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in">Must remember, we
are still vulnerable to network failure errors.<br/>
</p>
</div>
</blockquote>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Yes,
they are keenly aware of that. It’s a big task and won’t
happen for a while. But it will happen.<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
don’t like the Pony language syntax. I don’t like
anything that looks like Algo-60. Pony is a language,
compiler and runtime implementing Orca. The other stuff
is good. And I’ve not had much time to use it; I
suspect I could like it more.</span><o:p></o:p></p>
</blockquote>
</blockquote>
<p style="margin-left:.5in">No argument from me! Squeak is a
language, a compiler and a profound image-based runtime. Is
there another language with such an image-based runtime? I
think not.<o:p></o:p></p>
<p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Yes,
we all love Smalltalk. It’s still too slow. <o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We’re
not talking about coding ergonomics and testing dynamic. We
all agree that Smalltalk is a better that way to code and
interact with the evolving program. But that’s not what the
thread is about. This is all about speed and scale across
cores, CPUs, and machine nodes. The solution must be
implemented close to the metal (VM). </span></p>
</div>
</blockquote>
The Way<br/>
<ol>
<li>Get it to run;</li>
<li>Get it to run right;</li>
<li>Get it to run fast.</li>
</ol>
<p>This has always been the Way. If that third step requires a per
Actor GC, then so be it. <br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It
can’t be an add-on framework. We need an Actor class and
syntax for making actors and their async behaviours. </span></p>
</div>
</blockquote>
<p>This we have exactly in CapabilitiesLocal and Raven.<br/>
</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Then
we need the VM to understand the new format and bytecodes
associated with actors.</span></p>
</div>
</blockquote>
<p>We have had no need for special bytecodes. Squeak just does [:it
| it with: #Class] I have thought of making the VM aware of ERefs.
I am busy on layer 5, building secure Sessions for SSL, SSH,
Signal and TLS 1.3, as I mentioned. Then I will turn to Raven,
again.</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:01e901d624f6$79095da0$6b1c18e0$@uurda.org">
<div class="WordSection1">
<p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Shaping</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Kindly and with good fortune,
Robert</pre>
</body></html>