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

[via Digitalmars-d]

On Wednesday, 14 May 2014 at 20:02:08 UTC, Ola Fosheim Grøstad 
wrote:
> On Wednesday, 14 May 2014 at 19:45:20 UTC, Marc Schütz wrote:
>> - We have external code programmed in languages other than D, 
>> most prominently C and C++. These don't provide any type 
>> information, therefore the GC needs to handle their memory 
>> conservatively, which means there can be false pointers => no 
>> deterministic destruction.
>
> Oh yes, I agree.
>
> 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...

>
>> - Variables on the stack and in registers. In theory, the 
>> compiler could generate that information, or existing debug 
>> information might be used, but that's complicated for the GC 
>> to handle and will probably have runtime costs.
>
> 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.

>
>> - Untagged unions. The GC has no way to figure out which of 
>> the union fields is currently valid. If any of them is a 
>> pointer, it needs to treat them conservatively.
>
> So you need a function that can help the GC if the pointer 
> fields of the union don't match up or don't point to class 
> instances.

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.