Workaround for typeid access violation

Etienne Cimon via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 18 09:16:25 PDT 2015


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.


More information about the Digitalmars-d mailing list