Robin, Good points. Given that Object.hashCode() implementation sortof, kindof depends on a copying mature space, does it make sense for the GC to "own" the Object.hashCode() implementation? That way, we eliminate the vm-wide debate about giving object hash one or two or even 12 header bits. It all becomes a local problem of GC implementation. No need for negotiating with the rest of the VM :)
From a top-level how about giving the GC one byte of object header to
do hash plus whatever it wants? I realize it would be nice to have an "expando" object model in Harmony that would allow arbitrary number of header bits for a) tib ptr, b) default hash code, c) lock info and d) GC info. I worry that this would be too disruptive to the code base right now. Can we make do with the above proposal?
Just to be clear, the two-bit Object.hashCode() scheme I refer to is the one in section 3.3 of, "Space- and Time-Efficient Implemention of the Java Object Model" by David Bacon, et al. I think this is also the scheme Ivan Volosyuk is refering to and has an implementation of. On 8/28/06, Robin Garner <[EMAIL PROTECTED]> wrote:
> From talking to > the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte > of object header for private use. Its unclear to me if this will be a > performance problem for a product JVM. Yep. We found a nice mark-sweep implementation technique that greatly reduces the cost of sweeping if we have several mark bits available, but after 4 or so bits the advantage tails off, so there is room for compromise with the VM's need. On the other hand I'm currently looking at other ways we could speed up GC if there were a few extra header bits available, so the more bits available to GC, the better - and these will generally be tunable parameters that can be traded against the VM's other needs. > I think the hashCode can be > reduced to one bit plus the object's current address at first > HashCode() invocation. I'd put this hash bit in the GC byte. And > make the GC byte the lowest byte in the header word. The remaining > 3bytes could be used for fat/thin locks. In GenMS, where there is a copying nursery and a non-moving mature space, you could indeed get away with 1 bit for hashcode, with a different meeaning in each space. In a heap where objects could move more than once, I think you might still need 2 bits. cheers --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
