From: Tim Wilkinson (tim@transvirtual.com)
Date: Fri Feb 12 1999 - 15:01:32 EST
Ah heck - what a pain. Kaffe tries to align structures like C - so it trys to
make sure that the alignment of serialVersionUID is on it's natural boundary
(for the sparc at least - the x86 doesn't insist on 8 byte boundaries).
I guess the alignment code is wrong - I will take a look.
Tim
PS. a 'temporary' fix would be to swap the serialVersionUID with method ...
I think.
Godmar Back wrote:
> 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
-- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA. Email: tim@transvirtual.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:07 EDT