[Mono-list] x86 JIT

Kevin Scott jks6b@cs.virginia.edu
Wed, 11 Jul 2001 16:31:58 -0400


In message <000201c10a42$f7dd4f80$1699b48c@cp102230a>, "John Zedlewski" writes:
>> Maybe I'm missing something, but how does this scheme communicate to
>the
>> collector which temporaries and registers contain pointers to objects.
>
>Kevin, 
>  You're actually dead right, the scheme I mentioned doesn't say
>anything about registers or temps, because I think that would be highly
>dependent on the exact garbage collector style you want to use.  I think
>the traditional approach is to say that GC can only occur at inserted
>"safe points" where the format of the temporaries and registers is
>known. Since CLI lets you stack-allocate local objects, it doesn't use
>nearly as many local references to GC-described objects as, say, the
>JVM, so we get off kind of easy with the number of local sites we need
>to monitor.

Right.  But I thought you were proposing a scheme for a gcc-based CLR to
do precise garbage collection.  It seems to me like describing pointer
maps to gcc and getting the compiler to accurately maintain them through 
the optimization process is going to require more work than just inlining 
a function at the object allocation site.  Stack allocation or no, you're 
still going to have registers and possibly temps pointing to heap allocated 
objects.  And if you don't know when and where a pointer might be in a 
register or temporary, you're going to have be conservative when collecting 
objects.  

It seems like the advantage of stack allocation is that it doesn't so much
matter that your GC is conservative -- stack allocated objects just go away 
when the allocating function returns.  And maybe that plus a conservative
collector to get rid of most of the dead heap objects is good enough for 
most programs.

-K

--
Kevin Scott                          PhD Student,  Dept. of Computer Science
kscott@cs.virginia.edu                       University of Virginia       
http://www.cs.virginia.edu/~jks6b            +1 804 982 2391 (work)