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

[Todd Blanchard]

Since we’ve dropped into the whole thread thing - I’d like to mention that I’ve done a lot of iPhone and some Mac programming with Grand Central Dispatch (GCD - open source versions available as libdispatch) and have found that model easy to use and powerful. The key trick being to only manipulate the GUI and stateful entities on the main thread/queue while shuffling the heavy lifting off to lower priority queues via closures that steer clear of data that isn’t thread safe to access.

It works very well and this idea of mini worker images sounds like it might be a good fit for that model.

It would take some work to pull in libdispatch and restructure the vm but I feel like that might well be the way forward.

Sent from the road

> On Oct 18, 2017, at 22:12, Ben Coman <btc at openinworld.com> wrote:
> 
> 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/a9045eb3/attachment.html>