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

[via Digitalmars-d]

On Thursday, 15 May 2014 at 12:56:13 UTC, Ola Fosheim Grøstad 
wrote:
> 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?

You don't know what the C function does with them. `scope` can be 
used to tell the compiler that the function doesn't keep them 
after it returned. Of course the compiler can't verify it, but it 
could only allow GC pointers to be passed as scope arguments.

And of course, it would need to know which pointers _are_ GC 
pointers in the first place.

>
>>> 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.

Exception handling info is not detailed enough. It only contains 
addresses of cleanup code that needs to be called during stack 
unwinding, but nothing about the objects on the stack, AFAIK.

>
>> 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.