radical ideas about GC and ARC : need to be time driven?

via Digitalmars-d digitalmars-d at puremagic.com
Thu May 15 05:56:12 PDT 2014


On Thursday, 15 May 2014 at 12:44:56 UTC, Marc Schütz wrote:
> On Wednesday, 14 May 2014 at 20:02:08 UTC, Ola Fosheim Grøstad 
> wrote:
>> However, you could have rules for collection and FFI (calling 
>> C). Like only allowing collection if all C parameters that 
>> point to GC memory have a shorter life span than other D 
>> pointers to the same memory (kind of like borrowed pointers in 
>> Rust).
>
> Some kind of lifetime annotation would be required for this. 
> Not that this is a bad idea, but it will require some work...

Isn't it sufficient to let the backend always push pointers that 
could be to GC memory on the stack in the functions that calls C?

>> The easy solution is to use something that is to define safe 
>> zones where you can freeze  (kind of like rendezvous 
>> semaphores, but not quite).
>
> This helps with getting the registers on the stack, but we 
> still need type information for them.

Yes, but you have that in the description of the stack frame that 
you look up when doing precise collection? You need such stack 
frame identification utilities for doing exception handling too.

> Which of course requires type information. And existing unions 
> need to be updated to implement this function. I guess 
> sometimes it might not even be possible to implement it, 
> because the state information is not present in the union 
> itself.

Then the compiler could complain or insist that you use a 
conservative GC.


More information about the Digitalmars-d mailing list