[RFC]Proposal for better garbage collection

[H. S. Teoh]

On Thu, Feb 23, 2012 at 06:01:48PM +0100, deadalnix wrote:
[...]
> Additionnaly, the stack is made like a linked list. Each function
> calling another one register the return address. With this
> information, we can have data about what is on the stack except for
> the very last function called with no runtime overhead. This is
> another alternative.

Yep. In one of my replies I considered the possibility of storing a
function ID on the stack, but that may not be necessary if the GC has
access to compile-time static info about each function, so just by
seeing the return address it knows which function it is, and can figure
out where the pointers are. (Of course there are other issues that need
to be addressed... but we can't decide on that without actual data.)


> But you have to consider that, even with a mask, you are not sure
> that what is marked as a pointer is a pointer. A memory location can
> represent different thing during a function execution. So thoses
> values can only be considered as probable pointers, or we disable
> some compiler optimizations. As we cannot be sure, the point 2/ stay
> valid.

I believe his proposal was for the function to manually update these
bits as it runs. It does introduce a lot of overhead. And like you said,
without actual hard data to show whether or not this overhead is
justified (offset by improved GC performance), how do we know that we
should do this at all? How do we know we aren't making it worse?


> Granted the overhead of the operation, it ay not worth it. To know
> that, we need actual data on how much data is the stack is actually
> pointer, and how much false positive we get. As the future is 64bits,
> I'm not sure it is interesting for us.

Actually, I believe David Simcha *is* considering the possibility of precise
scanning. But the proof is in the actual benchmarks. We don't know if it
will help or not unless we have real data to back it up.


T

-- 
Real Programmers use "cat > a.out".