Handling of static fields

[Per Bothner]

Kaffe allocates all the static fields of class in a single
buffer (pointed to by Class.staticData); the location of the actual
field value is then given by an offset into that buffer.  The offsets
are specified by FIELD_OFFSET, which is the member boffset in the
struct Field.

In G++, a static field is a VAR_DECL; the actual location
is given by the assembly-level label of the VAR_DECL.
I.e. a static field is acts very much like a normal
static variable, except it is "nested" inside a class.
The debugging information passed to gdb also specifies the
static field by using the assembler-level label of its location.

These approaches are incompatible.  The Kaffe approach is not
suitable for G++, because in C++ static fields belonging to a
class can be defined in different compilation units.  So the
choice is to either modify Kaffe to be compatible with G++ and
Gdb, or extend G++/Gdb so they can handle Kaffe-style static
fields *in addition to* G++-style fields.  I think modifying
Kaffe is preferable.

So what I am proposing is that we modify:

	struct Field {
		...
		int boffset;  /* field offset in bytes */
	};
	#define FIELD_OFFSET(FLD)       ((FLD)->boffset)

to:

	struct Field {
		...
		union {
			int boffset;  /* non-static field offset in bytes */
			void *addr; /* static field location */
		} value;
	};
	#define FIELD_OFFSET(FLD)       ((FLD)->value.boffset)

The value.boffset member would only be used for a non-static field.
For a static field, value.addr would point to the actual location.
The Class.staticData would be removed.  Each of the static fields
are allocated independently, instead of in a buffer, at least
conceptually.

Advantages:
+ Compatibility with C++, which may ease future sharing of Java/C++ classes.
+ No changes needed for (non-Java-specific parts of) Gcc.
+ Minor changes needed for Gdb, but only for debugging dynamically loaded
classes (i.e. those not pre-compiled by Gcc).
+ Slightly faster GETSTATIC/PUTSTATIC operations (don't need to get
the class's staticData or add an offset). 
+ One less field (staticData) needed in each Class.
+ Same amount of space for each Field (on most architectures).
+ Relatively simple changes needed for Kaffe.

The main dis-advantage I can see has to do with GC and memory management.
Conceptually, each static field is allocated independently, which means
we get the GC space overhead for each field, rather than (at most)
once per class.   The static field could still be allocated in a
single buffer, but then the value.addr pointer in each struct Field
points into the interior of an object, which may complicate or slow
down GC.  However, that shold not be a problem if the GC is smart
enough to do special scanning for classes and associated data
- which we probably need to do anyway.

Anyone see anything wrong with this plan?

	--Per Bothner
Cygnus Solutions     bothner at cygnus.com     http://www.cygnus.com/~bothner