Interpreter progress...

[Godmar Back]

A short follow up to a mail Kresten sent several months ago, because
an issue he hints at is still present in libgcj:

A long time ago Kresten wrote:
> 
> I spend most of my time yesterday hunting down a couple of gc-bugs,
> ... things like the storage for static variables was disappearing
> under my nose after a while.  The Boehm collector really is quite
> precise!
> 

I looked at the code that marks static variables in boehm.cc, and I think
it should be enclosed in "#if defined(INTERPRETER)", not just a comment
that says "for the interpreter, ..."

Specifically, I got tripped up by this:

              // also, if the static member is a reference,
              // mark also the value pointed to.  We check for isResolved
              // since marking can happen before memory is allocated for
              // static members.
              if (JvFieldIsRef (field) && field->isResolved())
                {
                  jobject val = *(jobject*) field->u.addr;
                  w = (word) val;
                  MAYBE_MARK (w, mark_stack_ptr, mark_stack_limit,
                              c, c8elabel);
                }


At first glance, this looks like it would also work for precisely
walking the static data of precompiled classes.  This is not the case,
however, because the "UNRESOLVED" flag (which causes "isResolved()"
to fail) is *not* kept consistent with the actual value of the static
variable.  In other words, what can happen is that you have a static
variable whose field is "UNRESOLVED", yet it is already pointing at a 
valid Java object.  The meaning of "UNRESOLVED" is only with respect to
the *type* field of the static variable field.

An example for where that happens is a static variable defined like this:

  static char [] newline = System.getProperty("line.separator").toCharArray();

This inconsistency does not occur in the interpreter; it also currently
doesn't cause problems in libgcj because the data segment is walked 
conservatively, and there is always a pointer from the data segment
to the Java object.  However, should you ever want to implement precise 
walking of static class data, be aware of this potential problem and
do not assume that the existing code will simply work.

    - Godmar