[Vm-dev] Sista alternate bytecodes + Java Bytecode ?
holger at freyther.de
Wed Oct 18 10:39:23 UTC 2017
> On 18. Oct 2017, at 01:09, Raffaello Giulietti <raffaello.giulietti at lifeware.ch> wrote:
> Hi Jan,
> I'm not arguing whether the complex JVM model (java.lang.Thread) is better than the simpler Smalltalk model (Process).
> What I mean is that to execute existing JVM bytecode, the VM must also support genuine multi-threading, with all the related intricacies stemming from its memory model. Without MT, many useful, mature, maintained JVM libraries out there cannot work, as they depend, whether knowingly or not, whether directly or indirectly, on MT support from the VM.
my cents... Many people confuse (including myself) concurrency with parallelism. There is concurrency in Smalltalk and Java but sadly the current VM offers no parallelism. I haven't looked at Java bytecode > 1.5 but what instructions require _parallelism_? Last time (university) I checked the Java memory model allowed "delays" of when a store becomes visible in other threads but didn't require it.
What OpensmalltalkVM has is that one running Process can be interrupted because of IO or other events. Could you elaborate on what runtime behavior Java libraries expect? In the past Paolo Bonzini added Java support to GNU Smalltalk using GNU Classpath by implementing the primitives in Smalltalk, a bytecode converted and custom class loader.
Last but not least. I would love to have parallelism in Pharo but the "share everything" approach (and put a giant lock everywhere, then more granular) seems to not be the future. E.g. the Erlang actors (yeah coming from somewhere else with Smalltalk legacy) or CSP as used in Go might be better? And to completely derail this thread (none of this being my idea)... maybe the future is in a meta-vm... dispatching tiny images over a number of CPU cores and machines(!) sending messages and objects from one image to another (with VM support to avoid the copying of them). Atomically replacing one image (and externalizing/internalizing the state) with a metaBecome:.
 Leaving threaded alien aside
 We have already seen running multiple images on one VM, and spawning new images from one.
More information about the Vm-dev