[gclist] Two conservative collectors

[Boehm, Hans]

Are you thinking of Stichnoth, Lueh, and Cierniak, "Support for Garbage
Collection at Every Instruction in a Java Compiler", PLDI 99?  I think they
actually restrict optimization by disallowing interior pointers.  But that's
probably fixable.

There are many other systems that encode this information at safe points.

In a pure Java system, that's very reasonable.  But I don't think standard
debugging information is sufficient.  Hopefully we agree that it's
insufficient if you want to move all objects, since you then need to know
about ALL temporaries.

Hans

-----Original Message-----
From: Tom Tromey [mailto:tromey@cygnus.com]
Sent: Thursday, November 18, 1999 2:42 PM
To: Boehm, Hans
Cc: 'Charles Fiterman'; gclist@iecc.com
Subject: RE: [gclist] Two conservative collectors


>>>>> "Hans" == Boehm, Hans <hboehm@exch.hpl.hp.com> writes:

Hans> 1) If I'm inside the call to g in
Hans> 	f() + g(13)
Hans> where f returns a pointer (and has been evaluated first) and g returns
an
Hans> integer, I know of no way to ask about the (temporary) pointer value
Hans> returned by f.

I've read a paper where the authors changed their compiler to generate
tables to allow precise marking of the stack.  The tables encoded lots
of information so that they would continue to work in the presence of
aggressive optimization.  Unfortunately I don't have the paper handy
and I don't remember anything that would help me find it again...

T