[Vm-dev] Multi-Image Sista VM?

[Clément Béra]

On Sun, May 3, 2020 at 2:59 AM Robert <robert.withers at pm.me> wrote:

> Hi Clément,
> On 5/2/20 2:47 PM, Clément Béra wrote:
>
>
>
> On Sat, May 2, 2020 at 8:06 PM Robert <robert.withers at pm.me> wrote:
>
>>
>> On 5/1/20 2:59 PM, Clément Béra wrote:
>>
>> The Hydra VM from Igor was doing exactly that.
>>
>> Stellar! Could we reintegrate with the latest squeak.cog.spur?
>>
>
> Hydra was a fork of the pre-stack VM. I don't know where is the code. Igor
> may be able to answer. Ask him.
>
> Do you have Igor's email? I will ask.
>
siguctua at gmail.com


>
> As Tim said, it's not clear there is a high benefit from running many
> image on 1 VM vs multiple images, each on their VM. One advantage could be
> the speed of communication between the images. However, it's possible to
> have a byte array on a Posix Shared Memory section (Pavel had made some FFI
> bindings to do that) that is shared between multiple images. I'm sure with
> a clever design one could share more than just a byte array. With a shared
> memory section and external semaphores, it's not clear there are good
> use-cases that would require multiple images on 1 VM.
>
> I see your and Tim's point here. When asked I have always reported that
> the way to take advantage of multiple cores is to run multiple images on
> their own VM. The realm of actor mobility I have not worked on.
>
> Actor Mobility: I think it works just like a eukaryotic cell. with
> proteins produced through the ribosome and ER, then packaged for delivery
> with a network motif, and sent through the Golgi Apparatus to be delivered
> then unpackaged. Normally an Actor is not passByCopy, but a remoteERef is
> sent abroad. To convert a passByReference object into a passByCopy,
> serialize it into bytes and wrap it in a package, which is passByCopy. Send
> it forth, unpackaged remotely, it becomes a passByReference Actor again.
> Use this to communicate between VM/image/Vat/eventLoop.
>
>
> The Actor model in Newspeak is also somewhat similar to that, though part
>> of the image is shared between threads.
>>
>> I believe the Newspeak Actors are implemented with local capabilities,
>> from ELib, just as my CapabilitiesLocal package. DoIt:
>>
>> Installer ss project: 'Cryptography'; install: 'CapabilitiesLocal'.
>>
>> works. Both implement a ELib Promise system with async resolution and
>> resolved promise reactor invocation.
>>
>> Would you be able to say a few words about their use of shared memory,
>> please? As well, what could you mention about their use of promises,
>> regarding Ease of use, understandable code, tips & tricks with promises?
>>
>
> I think Ryan could answer in a better way.
>
> Did you mean to copy Ryan? I would definitely like to hear of NewSpeak in
> this regard.
>

Ask him directly. He will answer better.

>
> My understand is that NewSpeak have value objects, which are immutable,
> and such objects can be shared between actors, including classes, methods
> and so on.
> Not sure about promise. Ryan, can you answer?
>
> Value objects are immutable, thus sharable. Hmmm. Thinks about that.
>
> K, r
>
>
>
> K, r
>>
>>
>> Not sure what is the status of these projects though.
>>
>> On Wed, Apr 29, 2020 at 8:43 PM Robert <robert.withers at pm.me> wrote:
>>
>>>
>>> I have not read about this anywhere I can remember. Would it be possible
>>> to run two images on one VM?
>>>
>>> Preggo,
>>> Robertotini
>>>
>>> Sent from ProtonMail Mobile
>>>
>>
>>
>> --
>> Clément Béra
>> https://clementbera.github.io/
>> https://clementbera.wordpress.com/
>>
>> --
>> Kindly,
>> Robert
>>
>>
>
> --
> Clément Béra
> https://clementbera.github.io/
> https://clementbera.wordpress.com/
>
> --
> Kindly,
> Robert
>
>

-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200503/218138eb/attachment-0001.html>