From: Tim Wilkinson (tim@transvirtual.com)
Date: Fri Feb 12 1999 - 16:59:50 EST
I guess moving the Object into the classes is fine (it matches the internal
representation after all) so go ahead and make it happen - I can't think of
any reason it'd cause problems.
Cheers
Tim
Godmar Back wrote:
> I thought of that possibility too.
>
> That would put us up to 18 bytes overhead per object.
> 2*4 for linked list (which is stupid if you don't have a treadmill).
> 2 bytes for gc status
> 4 bytes for header
> 4 bytes for lock.
> ----
> 18
>
> I would love to see that optional.
> Ideally, I'd like a 4-8 byte overhead for objects with a non-incremental
> collector that uses a mark stack.
>
> Also, I think what gcj does is wrong. I believe EF's approach is better:
> store the object hash for a moving collector, and use 2 bits to make
> the uncontended case for locking fast. If a lock is contended, then it's
> no biggie to have to look up the structure. Sooner or later, the gcj folks
> may realize that too.
>
> To fix this specific problem, my gut feeling is that simply moving
> the base part into the object, as Alexandre and I proposed, should fix it
> and is doable with few changes to kaffeh and a few header files.
> What's making you so hesitant to try that? Or is there other objections
> that I haven't thought about?
>
> - Godmar
>
> >
> > Well before I go mad trying to fix this thing - we might just want to
> > bring in the extra locking field into the Object structure by default -
> > okay this increases the size of Object by 4 bytes but it does solve the
> > alighnment problem. Also, this will have to happen for the GCJ stuff
> > anyhow so perhaps it's not a bad thing to do now?
> >
> > Tim
> >
> > --
> > Tim Wilkinson Tel: +1 510 704 1660
> > Transvirtual Technologies, Inc., Fax: +1 510 704 1893
> > Berkeley, CA, USA. Email: tim@transvirtual.com
> >
> >
> >
> >
-- 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