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

[Raffaello Giulietti]

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.

I understand Ben's dream to have a Smalltalk VM able to execute JVM 
bytecode. But as long as one cannot execute arbitrary JVM code, I wonder 
what the value of extending the Smalltalk VM to support it would be, 
given the huge efforts this task would require even without MT support.



Raffaello



On 2017-10-17 18:04, Jan Vrany wrote:
>   
> Hi there,
> 
> On Tue, 2017-10-17 at 16:53 +0200, Raffaello Giulietti 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.
> 
> In my opinion, the "vastly simpler" model of current smalltalk VMs
> makes the implementation of Java execution on top of them simpler, not
> more difficult.
> 
> As for the real-world code, I do not recall any difficulties w.r.t.
> smalltalk's "vastly simpler" model.
> 
> Jan
> 
>>
>>
>>
>> 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/201
>>> 71003/4c21a419/attachment.html>
>>>
>>>
>>
>>