From: Godmar Back (gback@cs.utah.edu)
Date: Fri Feb 12 1999 - 12:46:14 EST
Alias fails for me on the sparcs.
The reason is that the field offsets are computed wrong.
The struct is defined as:
typedef struct Classkaffe_io_ObjectStreamClassImpl {
struct Hjava_lang_String* name;
struct Hjava_lang_Class* clazz;
jint method;
jlong serialVersionUID;
struct Hkaffe_io_ObjectStreamClassImpl* superstream;
struct Hjava_lang_Class* iclazz;
HArrayOfObject* fields;
} Classkaffe_io_ObjectStreamClassImpl;
And then as
#define HandleTo(class) \
typedef struct H##class { \
Hjava_lang_Object base; \
struct Class##class data[1]; \
} H##class
This is the offset we think it uses:
GCLayout for java/io/ObjectStreamClass:
offset= 4 nbits= 1 01 fsize= 4 (name)
offset= 8 nbits= 2 011 fsize= 4 (clazz)
GCLayout for kaffe/io/ObjectStreamClassImpl:
offset= 16 nbits= 4 01100 fsize= 4 (method)
offset= 24 nbits= 6 0110000 fsize= 8 (serialVersionUID)
offset= 32 nbits= 8 011000001 fsize= 4 (superstream)
offset= 36 nbits= 9 0110000011 fsize= 4 (iclazz)
offset= 40 nbits=10 01100000111 fsize= 4 (fields)
In reality, however, it uses
(gdb) p &cls.base
$2 = (Hjava_lang_Object *) 0x165008
(gdb) p &cls.data
$3 = (struct Classkaffe_io_ObjectStreamClassImpl (*)[1]) 0x165010
So the data start at offset 8, and not 4. As a result, everything is
off by 4.
What is happening is that it aligns the "data" part at
an 8 byte boundary, because that's the maximum of the member variable
sizes (serialVersionUID is a jlong).
However, the superclass ObjectStreamClass does not need to be aligned
at a 8 byte boundary because it does not have a 8 byte element in it.
First, the offsets and the gc_layout tables are computed wrong.
This may be fixable.
The bigger problem I see is that this totally breaks the way in which
we compute offsets. It's no longer possible to cast a
kaffe/io/ObjectStreamClassImpl to its superclass java/io/ObjectStreamClass.
We would have to align every object start (the "data[1]") to the maximum
possible alignment, because the alignment of data[1] can change depending
on what alignment is require for subclasses.
On a related note, Tim uses an array of Lkaffe/util/Ptr; to store
"Field" ptr in it. This is something the gc does not handle yet. It
would try to mark all pointers in it precisely, which is not necessary,
since Fields are not subject to gc. I think we should change gcFuncs.c
to not walk ref arrays if the element type is the PTRTYPE.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:07 EDT