On Thursday, 18 June 2015 at 15:43:10 UTC, Wyatt wrote:
On Thursday, 18 June 2015 at 15:19:19 UTC, Etienne wrote:
On Thursday, 18 June 2015 at 15:09:46 UTC, Wyatt wrote:
This comes to mind, along with the citations:
http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/local-gc.pdf
-Wyatt
That's exactly what we're talking about, but we do the work
that was done by the globalisation policy by using the `new
shared` keyword.
Maybe I misunderstood. My interpretation was you were
disallowing references from shared heap to local heap and
Exactly, unless you cast(shared) before you copy into the global
heap - the local object must be kept trackable in the local heap
or space. In any case, the shared is recursive and disallows
this, so it's perfectly suitable to keep a shared GC consistent.
obviating the whole globalisation problem. No migrations; just
explicit marking of global objects with "new shared". (Though
I'm curious how you handle liveness of the global heap; it
seems like that depends on information from each thread's
allocator?)
The global heap and every thread will be scanned in stop the
world setting just like the current GC. However, the idea is to
use it less by making it exclusively for objects that were
created with `new shared` `new immutable` `.idup` or `.sdup` (so
that we can duplicate local objects into the shared GC
conveniently)
In all of my security library (Botan) or TCP library (libasync)
or even the vibe.d implementation at
https://github.com/etcimon/vibe.d I haven't encountered a single
instance of an object that was moved to another thread. The
shared GC will be known to be very rarely useful.
