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

Ben Coman btc at openinworld.com
Thu Oct 19 05:12:55 UTC 2017

Hi Raffaello,

Thanks for your perspective.
I guess also supporting the semantics of "Java Primitives" is more work
than just executing "Java Bytecode".

cheers -ben

On Tue, Oct 17, 2017 at 10:53 PM, Raffaello Giulietti <
raffaello.giulietti at lifeware.ch> wrote:

> Hi Ben,
> in addition to Clément's observations, you should not forget that much
> existing JVM bytecode depends on the multi-threading capabilities of any
> contemporary JVM implementation and its supporting platform libraries
> (e.g., java.util.concurrent.* for concurrency frameworks,
> java.util.stream.* for parallel streams, etc.)
> So, besides the humongous work mentioned by Clément, I can only imagine
> how hyper-humongous a work would it be to make the current OpenSmalltalk VM
> multi-threaded to accommodate the JVM computational model inherent in
> almost any real-world Java bytecode. Think only of the impact on the
> garbage collectors, for example. (Or on how to present multi-threading to
> Smalltalkers accustomed to the vastly simpler shared memory model of
> Process, where the happens-before relationship is trivial.)
> Greetings
> Raffaello
> On 2017-10-17 16:12, Raffaello Giulietti wrote:
>> Hi,
>> That question should be asked on vm-dev.
>> Just a detail, multibytecode set support is prior to the Sista
>> implementation, it was used for example in the context of Newspeak (Squeak
>> and Newspeak bytecodes supported together). Sista uses that feature, which
>> makes it look like new in the Pharo community since afaik no one used it
>> before in the context of Pharo.
>> Then yes it is feasible to have the VM process Java bytecode, but it's
>> humongous work. On the top my head, we would need to support typed
>> bytecodes for Numbers and exceptions at the bytecode level (which in
>> itself
>> is month of work, imagine raising an exception from Java/ST and catch it
>> from the other runtime, with multiple ensure/try finally in between)
>> Note that supporting the Java bytecode is far from enough to be able to
>> run
>> Java code (We also need core Java libraries support at least, including
>> exceptions/stack reification model that should be able to interact with
>> each other)
>> You can have a look at Smalltalk/X where the VM can run Java, C and
>> Smalltalk.
>> Regards
>> On Tue, Oct 3, 2017 at 1:57 PM, Ben Coman <btc at openinworld.com> wrote:
>>  > Just wondering about an exotic idea, with Sista facilitating alternate
>>  > bytecodes (btw, is that multiple bytecode sets within one Image?), how
>>  > feasible would it be to have the VM process Java bytecode?
>>  >
>>  > cheers -ben
>>  >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/
>> attachments/20171003/4c21a419/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171019/938221ea/attachment.html>

More information about the Vm-dev mailing list