[Vm-dev] [Pharo-dev] Pony for Pharo VM

Shaping shaping at uurda.org
Wed Apr 15 08:59:25 UTC 2020

Just to get in the right frame of mind, consider that because of the Blub Paradox (http://www.paulgraham.com/avg.html) 
you are going to have a hard time convincing people to "change to this language because of Feature X"
just by saying so.  You need to dig deeper.  


The Pony compiler and runtime need to be studied.


I’m not trying to convince; I’m presenting facts, observations, and resources for study of the problem and its solution.  Hardware constraints now are intensely multicore, and everyone knows this.  The changing programming paradigm in apparent.  Hardware structure is forcing that change.  Convincing yourself will not be difficult when you have the facts.   You likely do already, at least on the problem-side.  


The issue is not whether to use Pony.  I don’t like Pony, the language; it’s okay, even very good, but it’s not Smalltalk.  I like Smalltalk, who concurrency model is painfully lame.  I like Orca because it works on many cores (as many as 64, currently) without a synchronization step for GC, and has wonderful concurrency abilities.  Pony and Orca were co-designed.  The deferred reference counts managed by Orca run on the messages between the actors (send/receive tracing).  GCs happen in Pony/Orca when each actor finishes its response to the last received message, and goes idle.  The actor then GCs all objects no longer referenced by other actors.  The runtime scheduler takes this time needed for each actor’s GCing into account.  No actor waits to GC objects.  An actor’s allocated objects’ ref counts are checked at idle-time, and unreferenced objects are GCed in an ongoing, fluid way, in small, high-frequency bursts, with very small, predictable tail latencies, as a result.  That’s very interesting if you need smoothly running apps (graphics), design/program real-time control systems, or process data at high rates, as in financial applications at banks and exchanges.


The issue is how most efficiently to use Orca, which happens to be working in Pony.  Pony is in production in two internal, speed-demanding, banking apps and in Wallaroo Labs’ high-rate streaming product.  Pony is a convenient way to study and use a working implementation of Orca.  Ergo, use Pony, even if we only study it as a good example of how to use Orca.  Some tweaks (probably a lot of them) could allow use of dynamic types.  We could roll our own implementation of Orca for the current Pharo VM, but that seems like more work than tweaking a working Pony compiler and runtime.  I’m not sure about that.  You know the VM better than I.  (I was beginning my study of the Pharo/OpenSmalltalkVM when I found Pony.)

Now I I took a quick look to see what I could learn about Pony 
and the main interesting thing is its "Reference Capabilities".
Indeed, it seems Pony's purpose is the POC for that research.
I watched two videos...

[1] Øredev 2017 - Joe McIlvain - Pony - A Language for Provably Safe Lockless Concurrency

[2] Sophia Drossopoulou - Pony for Safe, Fast, concurrent programs - Codemesh 2017

So my "quick" assessment is to consider Reference Capabilities not a Type System 
but a Meta-type System. 


Yes, ref-caps control sharing of both mutable and immutable objects.

 [2] says "They are not a property of an object, but define how I can look at an object."  To summarize the videos... 








So you say...
> I want to use the Pony concurrency model at the Smalltalk level.  That’s the gist of it. 

> Otherwise, I want a Smalltalk, not a statically compiled language.


I believe you have the wrong end of the the stick promoting that the VM 

needs to be redeveloped using Pony to get the Reference Capabilities 
at the Smalltalk level. 


See my recent response to Ken in vm-dev.  


After you Ahead-Of-Time compile the VM, the compiler

is left behind.  The features of the compiler don't automatically flow through

to Smalltalk level. 



Yes.  JIT and AOT are needed.  Adjustments need to be made for dynamic typing, but such adjustments need not violate invariants needed to provide the ref-cap concurrency guarantees.  


A third option could be to extend to the existing "Immutability capability" of the VM.  


Ref-caps control access to both immutable and mutable objects.  Pony ascertains at compile time that only one actor at a time can hold a reference to a mutable object at runtime.


The six Reference Capabilities might be stored in the Spur Object Header 

using a re-purposed Immutability bit plus the two free "green" bits.



We can’t use a single big system heap, and also use the actor model and many cores productively.  


The big heap must go.


That’s the crux of what we need to learn at this juncture.  I’m not sure everyone is getting this.  I don’t need to convince you; you can do that for yourself.  We don’t currently have a better choice of programming model or memory management, if we want maximum speed, and are paying attention to hard constraints.  Multicore hardware is here to stay.  If you know a way to use your multicore CPUs more efficiently than by use of actor-based programming and Orca memory management, please share your facts.


Everyone needs to understand the big-heap problem in order to commit to fine-grain, actor-based (and therefore state-machine-based) programming.  We won’t realize productive multicore programming without an actor model.  We still need new tools to help, as mentioned, lest our state-machine programming be tedious and painful, causing us to default to old coding habits, and not make the needed state-machines.  I’m working on one of those tools.  Orca manages memory as fast as possible in an actor-based program/runtime, without any synchronization.  The big-heap problem has been solved for the statically typed case in Pony.  The lack of discipline/tools for building state-machines remains a broad problem.  Such new tools are therefore essential during the change of programming model.


I suggest studying the current Pony/Orca solution (see the Orca paper linked below), to see how it can be tweaked to accommodate dynamic types.  I’ve not studied the Pony compiler and runtime enough to be certain, but they may be closer to what we need, even if the first rough implementation of a Smalltalk-with-Orca must be AOT, instead of JIT.  We want both ultimately.  We should do first whichever is easiest to implement and test in small steps.   


"Reference Capabilities for Dynamic Languages" could be a strong PhD project.  


It’s a good idea.  Is this needed to make a Smalltalk that works with Orca?  I don’t think so.

Orca matters more than Pony.  But both can be useful to us.  Studying the Orca paper and its implementation in the Pony compiler and runtime is the easiest way to understand the constraints imposed by the current static type system in Pony—and how to change them to accommodate dynamic types.  


Everyone, please read and study https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_actor_languages.pdf if you are interested in building a VM/runtime that guarantees no data-races, and fully uses all your machine’s cores, with the least programming effort.


Then study Pony:  https://www.ponylang.io/

And ask questions on Pony Zulip:  https://ponylang.zulipchat.com/


(BTW, Zulip seems easier to use than Discord and e-mail.  Has anyone considered using it for the Pharo/Squeak lists?)








On Fri, 10 Apr 2020 at 17:56, Shaping <shaping at uurda.org <mailto:shaping at uurda.org> > wrote:
> Hi Ken.
> Not to discourage people, but I have not seen cases where a "strong
> type system would be able to scale for _real_ Smalltalk applications.
> You’re right.  It doesn't.  I'm not suggesting that.
> The type safety is not for app-level Smalltalk development.  It's for building the VM only.
> The six ref-cap ideas for sharing data reliably between actors are not hard to grasp, but they take some getting used to, and involve some mental load.  I don't want that much (concurrency-related or any other) implementation detail in the domain layer, much in the same vein as:  I don’t use Forth because I don’t want to see stack acrobatics (ROTs and DUPs, etc.) amidst domain-level state-changes (FirePhotonTorpedo).  It’s distracting.  It dilutes focus on the domain work/layer, and tends to cause mistakes there.
> The programmer’s domain logic and the concurrency-integrity provided by the ref-caps are different layers of thought and structure.  The ref-caps are, however, mixed freely with domain logic in current Pony code.  I think that’s a mistake.  But that’s how it is now.  I think of this layer mixing as an intermediate design stage of Pony.  I want to abstract-out some or all ref-caps as the VM is built. 
> Pony language is not the remarkable thing here. I see it as a better C or better Rust.  It’s very good (as Algol-60-ish-looking crap-syntaxes go), but that’s not what this is about.  It’s about the actor programming, the concurrency model, and the guarantees given by use of the ref-caps.  We would still obviously need to respect the Pony compiler’s determination of where ref-cap use is correct or not.  Your Pony program won’t compile if you don’t use the ref-caps correctly, and you don’t get the guarantees or a running program without the compile.  Much easier, therefore, might be to go the other way by changing Pony to support dynamic types without violating the invariants that allow the ref-caps (under the hood, abstracted out) to make the concurrency guarantees.  Work Smalltalk dynamism into Pony, instead of building a Smalltalk VM with Pony. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200415/30e81eae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 56596 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200415/30e81eae/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 70107 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200415/30e81eae/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image011.png
Type: image/png
Size: 108006 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200415/30e81eae/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image013.png
Type: image/png
Size: 57848 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200415/30e81eae/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image015.png
Type: image/png
Size: 77077 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200415/30e81eae/attachment-0009.png>

More information about the Vm-dev mailing list