GC, the simple solution

[Frank Benoit]

> I'm not throwing it away so fast, I've thought about it for several
> years <g>.
I meant myself, hehe.

>> If I call a func/method, I hold a valid reference to the object. While
>> this reference is copied down the stack, these are only temporary
>> reference. And all of them are release before the call returns to the
>> caller. You can ignore them all for RC.
> 
> 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.

>>> 3) in a multithreaded app, the incs and decs must be synchronized
>>
>> Isn't a atomic inc/dec enough?
> 
> That requires synchronizing.
> 
>> (Don't know anything about the
>> performance of the asm "lock" instruction)
> 
> It's slow enough to be noticable.
> 
> Yes, you can find out the beginning of an arbitrary pointer's memory
> block. But that isn't a cheap operation.

yikes, you are absolutely right.
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.

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


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

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

> Latency cannot be guaranteed even with malloc().
> 
> I don't know what constraints you have on the system you're developing.
> But when I've written real time interrupt code, the ISRs were written to
> not make any OS calls or any allocations. All they'd do is just gather
> data and post it to a FIFO buffer. A non-realtime thread would then pull
> the data out of the buffer and process it. The system would work without
> dropping data as long as the average (not maximum) processing time per
> datum was less than the data acquisition rate.

Yes, I will also not do any OS call, neither I would do a "new". And I
can easily check the code for not doing this. I even can do a check into
the GC allocator, that it is not called in a ISR.
But a moving reference can corrupt the working GC. And there is no way
to check for that.