[Vm-dev] Sista alternate bytecodes + Java Bytecode ?

Dimitris Chloupis kilon.alios at gmail.com
Wed Oct 18 10:47:14 UTC 2017


Well technically its feasible outside the standard scope of the VM, we have
afterall multithreaded FFI (OS threads are parrarel), I assume, though
never used it that it requires for all threads to join the main one in
order to be used. Maybe something could be done similarly for JVM as well,
join its threads before its passes bytecode to Smalltalk VM ?

On Wed, Oct 18, 2017 at 1:39 PM Holger Freyther <holger at freyther.de> wrote:

>
>
> > On 18. Oct 2017, at 01:09, Raffaello Giulietti <
> raffaello.giulietti at lifeware.ch> wrote:
> >
> > Hi Jan,
>
> Hey!
>
>
>
> > 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[1] 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[2] 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[3] 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:.
>
>
> regards
>         holger
>
>
> [1] Leaving threaded alien aside
> [2]
> http://git.savannah.gnu.org/cgit/smalltalk.git/tree/packages/java?h=3.2.5&id=4dc033eb76d82ff22266e7689c82a0ecd17ae3c6
> [3] We have already seen running multiple images on one VM, and spawning
> new images from one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171018/622e2e34/attachment.html>


More information about the Vm-dev mailing list