Re: class gc & future gc interface - progress

Date view Thread view Subject view Author view

From: Godmar Back (gback@marker.cs.utah.edu)
Date: Mon Jan 04 1999 - 02:05:30 EST


 I made some more progress.

To answer some of my own questions:

>
> Method.c.bcode.code / c.ncode.ncode_start (BYTECODE/JITCODE (*))

This is now allocated & freed explicitly.
Jitcode is still walked conservatively, to be on the safe side; but
it's kind of ugly since we do not store the length of the jit code.
I have to access gc-internal data structures to learn the length
when walking it.

Question: is the following chain of thoughts correct: only references
to classes or things that depend on classes could possibly be hardcoded
in the jit code. For each such reference, however, the constant pool
of the class will have a ResolvedClass entry that keeps all this stuff
alive. Therefore, there's no need to conservatively scan the jitted code.
Is this correct?
(Of course, I could just take it out and see what happens...)

> Method.exceptiontable (EXCEPTIONTABLE (*))

Here, I think only resolved catch_types have to be kept alive.
Easy enough.

> Method.ncode (?)

This one's still open. (I mean what's open is whether the markObject
can be made a MARK_OBJECT_PRECISE)

> Field.info (?)

This one was weird. I think was what happening was that this
somehow kept the static data alive, since one Field's address
coincided with their beginning. After keeping a pointer to the
static data in the class structure, I was able to precisely
mark FIELD_ADDRESS for static reference fields. I think that works.

> Class.constants.data (CONSTANT (*))

I scan these for RESOLVED_Strings and RESOLVED_Classes, which I
think is sufficient.

> Class.dtable (DISPATCHTABLE (*))

I don't think dtable kept anything alive: it only pointed to Method*,
which aren't a problem, and to trampolines, which are kept alive through
the methods they're serving: in particular, METHOD_NATIVECODE(m) points
to the trampoline.

So, the gcFuncs table now looks like this:

/* Standard GC function sets */
static gcFuncs gcFunctions[] = {
  { walkConservative, GC_OBJECT_NORMAL, 0 }, /* NORMAL */
  { walkNull, GC_OBJECT_NORMAL, 0 }, /* NOWALK */
  { walkObject, GC_OBJECT_NORMAL, 0 }, /* NORMALOBJECT */
  { walkPrimArray, GC_OBJECT_NORMAL, 0 }, /* PRIMARRAY */
  { walkRefArray, GC_OBJECT_NORMAL, 0 }, /* REFARRAY */
  { walkClass, GC_OBJECT_NORMAL, destroyClass }, /* CLASSOBJECT */
  { walkObject, finalizeObject, 0 }, /* FINALIZEOBJECT */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* BYTECODE */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* EXCEPTIONTABLE */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* JITCODE */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* STATICDATA */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* CONSTANT */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* FIXED */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* DISPATCHTABLE */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* METHOD */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* FIELD */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* UTF8CONST */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* INTERFACE */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* LOCK */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* THREADCTX */
  { walkNull, GC_OBJECT_FIXED, 0 }, /* REF */
};

While I'm typing this, I notice that there's still a walkConservative...
But incidentally, it turns out that the first type, GC_ALLOC_NORMAL,
isn't used at all. So we can get rid of it.

Btw, another optimization possibility is to identify those objects
that:
        a) do not contain references to other objects.
and
        b) whose classes are anchored.

and allocate them with a `walkNull' walk function.

        - Godmar


Date view Thread view Subject view Author view

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