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