Re: new gc interface

Date view Thread view Subject view Author view

From: Archie Cobbs (archie@whistle.com)
Date: Sun Jan 17 1999 - 20:53:21 EST


Godmar Back writes:
> I'm almost done with it (if I could only compile and run kaffe!)

Looks good! Pardon any ignorance exhibited below..

> extern void markObject(const void* obj); /* prev. MARK_PRECISE_OBJECT */
> extern void markAddress(const void* addr); /* prev. markObject */

So these could be used to support incremental GC, for example?
Ie, is all we lack for incremental GC is all the write barriers?

> The walk functions are only exported for convenience reasons.

Does the GC subsystem control the GC process? That is, does it
automatically invoke a GC pass when can't allocate memory? Or
would it make more sense to have the VM control the starting
and stopping of GC threads? Then whether the process was incremental
or not would be controlled by the VM rather than the GC subsystem.

> [ Once everything runs, I am considering making these functions part of the
> gc interface, although I still strongly oppose using run-time interfaces
> for subsystems that are static singletons at run-time. Where, in other words,
> you pay a significant performance penalty for no gain in robustness or
> flexibility. ]

Maybe using macros would help here. In any case, simplicity first,
get it working, and then optimize..

> One remaining dependence is that the gc still walks all threads.
> I'm not sure if that's really necessary. An alternative solution
> would register a thread as a root when its created und unregister it when
> it exits. We've had nasty race conditions with walking threads before,
> so I don't know whether my thinking here is correct.

I like the idea of the VM registering roots..

-Archie

___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:44 EDT