<div dir="ltr">Hi Raffaello,<div><br></div><div>Thanks for your perspective. </div><div>I guess also supporting the semantics of "Java Primitives" is more work than just executing "Java Bytecode".</div><div><br></div><div>cheers -ben<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 17, 2017 at 10:53 PM, Raffaello Giulietti <span dir="ltr"><<a href="mailto:raffaello.giulietti@lifeware.ch" target="_blank">raffaello.giulietti@lifeware.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Ben,<br>
<br>
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.)<br>
<br>
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.)<br>
<br>
<br>
<br>
Greetings<br>
Raffaello<br>
<br>
<br>
<br>
<br>
On 2017-10-17 16:12, Raffaello Giulietti wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
That question should be asked on vm-dev.<br>
<br>
Just a detail, multibytecode set support is prior to the Sista<br>
implementation, it was used for example in the context of Newspeak (Squeak<br>
and Newspeak bytecodes supported together). Sista uses that feature, which<br>
makes it look like new in the Pharo community since afaik no one used it<br>
before in the context of Pharo.<br>
<br>
Then yes it is feasible to have the VM process Java bytecode, but it's<br>
humongous work. On the top my head, we would need to support typed<br>
bytecodes for Numbers and exceptions at the bytecode level (which in itself<br>
is month of work, imagine raising an exception from Java/ST and catch it<br>
from the other runtime, with multiple ensure/try finally in between)<br>
<br>
Note that supporting the Java bytecode is far from enough to be able to run<br>
Java code (We also need core Java libraries support at least, including<br>
exceptions/stack reification model that should be able to interact with<br>
each other)<br>
<br>
You can have a look at Smalltalk/X where the VM can run Java, C and<br>
Smalltalk.<br>
<br>
Regards<br>
<br>
<br>
On Tue, Oct 3, 2017 at 1:57 PM, Ben Coman <btc at <a href="http://openinworld.com" rel="noreferrer" target="_blank">openinworld.com</a>> wrote:<br>
<br>
 > Just wondering about an exotic idea, with Sista facilitating alternate<br>
 > bytecodes (btw, is that multiple bytecode sets within one Image?), how<br>
 > feasible would it be to have the VM process Java bytecode?<br>
 ><br>
 > cheers -ben<br>
 ><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171003/4c21a419/attachment.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation<wbr>.org/pipermail/vm-dev/<wbr>attachments/20171003/4c21a419/<wbr>attachment.html</a>> <br>
<br>
</blockquote>
<br>
</blockquote></div><br></div></div></div>