This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the GCJ project. See the GCJ home page for more information.
> > The GC we're using now (and the one that will be in our runtime > release) is the popular Boehm conservative collector. It solves your > particular problem by stopping all the threads (using system-specific > voodoo) and then doing its work. Actually, the problem I was getting at does not occur with conservative collectors, so it won't be a problem with Boehm's. You seems to be describing the stop-and-collect character of Boehm's gc. My question is more concerned with what you do when your compiler creates type maps (information that says what machine state, including stack state refers to which objects). Then, it is often so that this information is not available for every instruction, but only a subset of instructions. An instruction for which it is available is called a gc point, because if a thread is stopped there, sufficient information is available to enable garbage collection. Now if you have a preemptive threading system, then threads can be stopped anywhere when you're trying to garbage collect: they do not necessarily have to have reached a gc point. That is the hard problem which is unique to precise collectors in a fully preemptive setting. (In a cooperative threading model, you can ensure that thread switches only occur at gc points.) Now I'm not suggestive here: I don't know how you would do it: maybe find a new way of encoding type maps that is contiguous, maybe find a quick way of rolling such threads forward; maybe even roll them backward; maybe allow only thread-local precise collection and do a conservative global collection. I think Amer Diwan suggested rolling forward in the paper I mentioned; though it is not known how efficient and doable that is. It sounds hard and inefficient. - Godmar