GC, the simple solution

[Walter Bright]

Frank Benoit wrote:
>> This fails if the passed reference 'escapes'. It can escape by being
>> assigned to a global, being assigned to a class member, being inserted
>> into some data structure that lives longer than the function, and being
>> returned by the function.
> Yes, and the compiler can catch these cases. With incr/decr the
> parameter reference you win nothing. So it should be possible to
> optimize them.

It can only do it if it has full source available. It also won't work 
for virtual functions, as it is not known at compile time what code will 
be called.

> So here comes the more ugly solution:
> Every pointer is allways a struct with the pointer to the data and a
> pointer to the refcounter.

It's the wrapper approach, with two allocations per allocation.


>>>> 7) Fixing the compiler to hide all this stuff from the programmer will
>>>> make it difficult to interface cleanly with C.
>>> hm, ok. Here is some more manual work necessary.
>>> If you give the last reference to a C lib, isn't this a problem for the
>>> MS GC also?
>> I don't know anything about the MS GC.
> 
> you do :) MS=mark&sweep

I thought you meant MS=Microsoft <g>. No, it isn't a problem, as it 
scans the C data segment and stack, too.


>>>> 9) Ref counting does not eliminated latency problems, it just reduces
>>>> them.
>>> Where do you mean is the latency with RC? The collecting work is done in
>>> the smallest pieces all the time. Only the allocation of new memory
>>> needs an unbound time to complete.
>> That's the same with gc. Only upon an allocation is the time unbound.
> And additional the time is unbound for the GC fullcollect...

The collector only runs during an allocation request - which means you 
can completely control when a collection can happen.


>>> But it does not need to stop all
>>> other threads. e.g. hardware interrupts don't need to be disabled.
>> GC doesn't require disabling hardware interrupts. It does not need to
>> stop any threads that do not hold references to GC allocated data.
> If you want to have you ISR written in D, you have two choices:
> a) be sure that you do not move a reference (refb=refa; refa=null;).
> This can end up in GC deleting a living object. If you cannot guarantee
> this, than
> b) disable the interrupting code also while the GC is running. But this
> is not acceptable, so go back to a) or have another GC.

c) code the ISR so it does not reference any gc allocated data. For 
example, use malloc() for dynamic data the ISR needs.

d) make sure any gc references used by the ISR have another reference to 
them that the gc will scan (such as in the global data segment).