> 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]
