GC conservatism -- again

[Steven Schveighoffer]

On Wed, 29 Dec 2010 14:00:17 -0500, Robert Jacques <sandford at jhu.edu>  
wrote:

> On Wed, 29 Dec 2010 07:37:10 -0700, Steven Schveighoffer  
> <schveiguy at yahoo.com> wrote:
>
>> On Tue, 28 Dec 2010 01:23:22 -0500, Robert Jacques <sandford at jhu.edu>  
>> wrote:
>>
>>> First, I'd like to point out that precise scanning of the heap (and  
>>> I'll assume this can be extended to globals), is a long standing  
>>> enhancement request.
>>
>> Yes, I know.  Does it also do precise scanning of the stack and  
>> global/TLS data?  Because that also needs to happen (I think you need a  
>> lot more compiler support for that) to really fix this problem.
>
> Globals and TLS should be possible, but the stack isn't without some  
> major architectural changes (tagging+filtering, dual-stacks, etc).

That is good, everything but stack is a step forward.

>
>>> Second, the false pointer problem disappears (for practical purposes)  
>>> when you move to 64-bit.
>>
>> I'm not sure I like this "solution", but you are correct.  This is  
>> somewhat mitigated however by the way memory is allocated (I'm assuming  
>> not sparsely throughout the address space, and also low in the address  
>> space).  It certainly makes it less likely that a 64-bit random long  
>> points at data, but it's not inconceivable to have 32-bits of 0  
>> interspersed with non-zero data.  It might be likely to have a struct  
>> with two ints back to back, where one int is frequently 0.
>
> Ah, but the GC can allocate ram in any section of the address space it  
> wants, so it would be easy for the upper 32-bits to be always non-zero  
> by design.

huh?  How does the GC control whether you set one int to 0 and the other  
not?

>
>>> Third, modern GCs (i.e. thread-local GCs) can further reduce the false  
>>> pointer issue.
>>
>> I'd rather have precise scanning :)  There are issues with thread-local  
>> GCs.
>
> The only issue with thread-local GCs is that you can't cast to immutable  
> and then shared the result across threads. And eventually, well have a)  
> better ways of constructing immutable and b) a deep idup, to mitigate  
> this.

I'm talking about collection cycles -- they necessarily need to scan both  
thread local and shared heaps because of the possibility of cross-heap  
pointing.  Which means you gain very little for thread-local heaps.  The  
only thing it buys you is you can assume the shared heap has no pointers  
into local heaps, and local heaps have no pointers into other local  
heaps.  But if you can't run a collection on just one heap, there is no  
point in separating them.

Plus it's easy to cast without moving the data, which is not undefined  
currently if you take the necessary precautions, but would cause large  
problems with separate heaps.

>
>> If we have the typeinfo of a memory block for the GC to parse, you can  
>> also rule out cross-thread pointers without thread-local GCs (for  
>> unshared data).
>
> Which basically creates all the problems of thread-local GC, with very  
> few of the advantages.

What are the advantages?  I'm not being sarcastic, I really don't know.

-Steve