From: Godmar Back (gback@cs.utah.edu)
Date: Sun Jan 17 1999 - 21:09: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..
>
No, these are good questions.
> > 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?
No.
> Ie, is all we lack for incremental GC is all the write barriers?
No. There's more to it.
I don't envision write barriers to be used in a brute force softcall
fashion. Instead, the gc subsystem will be required to emit code to
implement it. We'll get to that later.
Our (Jason and mine) current thinking is to implement two schemes:
One scheme would trade memory for promptness and would use Baker's
treadmill. The treadmill requires objects to be linked, but it's good
in that it doesn't have a sweep time.
The other scheme would be more similar to Boehm's gc: minimal overhead
per object, quick marking via markstack, but sweeping is slightly more
expensive.
Depending on how kaffe is used, one of the two would be chosen.
I'm not sure yet how this will be parametrized; whether at run time or
at configure or link time. This also affects the choice of the interface:
if I wanted run-time parametrization, I will need the current JNI-like
interfaces.
>
> 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.
Right now, the GC subsystem controls the GC process and decides when to
collect, as described in FAQ/FAQ.gcstrategy.
The issue as to whether to have the VM start and stop GC threads will
only arise should we implement asynchronous gc.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:44 EDT