[Vm-dev] Ideas on cheap multi-threading for Squeak / Pharo ? (from Tim's article)

Levente Uzonyi leves at caesar.elte.hu
Tue Jan 31 15:57:06 UTC 2017


On Tue, 31 Jan 2017, Stefan Marr wrote:

> 
> Hi Levente:
>
>> On 31 Jan 2017, at 15:22, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> 
>>> Also the question is does it really need to be objects? Alternatives include things like tuple spaces (think Linda), low-level shared memory buffers (Python and others, and apparently ECMAScript 2017).
>> 
>> You'd actually share a segment with objects stored in it. Low-level buffers are very restricting. They force you to serialize objects if you want to keep using them. And that has some unwanted overhead.
>
> What’s a segment?

It's a read-only chunk of memory holding objects.

> Who controls the lifetime of it?

It's permanent.

> Are you doing local GC plus global reference counting?

GC never touches that memory, because it can't change.

> Somehow you’d still manage those objects, no?

No.

>
>
>>> If you go with objects, the problem is that you need to support GC. And, I suppose Eliot will agree that GC for multithreaded systems isn’t exactly zero cost.
>> 
>> You don't need multi-threaded GC here, just many independent single-threaded GCs, which we have already.
>> Btw, this is the same thing Erlang does.
>
> I am probably missing something, but I’d think you need some global GC mechanism. If you got shared objects, you need to coordinate the local GCs.

All shared objects are permanent and read-only.

> In Erlang, most messages are copied, only large data chunks are shared by reference. So, that restricts the need for globally coordinated GC quite a bit, but you still need it as far as I can tell.

Here objects shared by reference would be permanent, therefore no GC would 
be required.

Levente

>
> Best regards
> Stefan
>
>
> -- 
> Stefan Marr
> Johannes Kepler Universität Linz
> http://stefan-marr.de/research/


More information about the Vm-dev mailing list