From: Godmar Back (gback@cs.utah.edu)
Date: Fri Feb 12 1999 - 16:56:24 EST
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.
---- 18I 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 > > > >
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:07 EDT