Workaround for typeid access violation

[Etienne via Digitalmars-d]

On Wednesday, 17 June 2015 at 20:19:45 UTC, Laeeth Isharc wrote:
> On Wednesday, 17 June 2015 at 19:52:41 UTC, Etienne wrote:
> https://github.com/etcimon/druntime/commit/7da3939637bd1642400dbed83e3b0ff2844386ac
>>>>
>>>> Only error was with a signal handler trying to allocate on 
>>>> the GC. I think it'll be worth it for me to use this from 
>>>> now on. There's no locking and possibly no stop the world.
>>>
>>> why 'possibly' ?
>>
>> I hadn't tested it when I wrote that message. I committed the 
>> changes today and my tests were successful in a thread-local 
>> GC, however I'm still scanning the other thread contexts. The 
>> only limitation is that you can't move objects between 
>> threads, a pointer must remain in the thread that created it 
>> if the object is used in another thread.
>>
>> > https://github.com/etcimon/druntime/commit/78a2bca1356e0514c516e5261649ca0bf686b4cb
>
> I am no compiler/runtime guru, but it sounds like if it were 
> possible to make this a swappable option for D this might be 
> very important.  Is this true, and how much work is involved in 
> making this industrial strength?

To me this is 100 times more stable simply because destructors 
can no longer be called from any thread. I'm also going to keep 
this implementation for its guarantee that destructors will be 
called. The absence of locking and stop the world makes it a very 
high performance GC.

Of course, the tradeoff is the absence of support in moving 
objects between threads. That's really an insignificant 
limitation compared to the above points. I don't expect it to be 
merged simply because nobody is familiar enough with this type of 
GC to have a say, except for what a GC shouldn't guarantee in 
general. And I'm really tired of people telling me what I can't 
or shouldn't do, when I'm brainstorming on this forum.