RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold

Tom Benson tom.benson at oracle.com
Thu Feb 12 20:14:10 UTC 2015


Hi,
I need reviewers and a commit sponsor for changes for bug 6764713, which 
will increase the size of the age field in an object header from 4 bits 
to 5. This will allow a maximum MaxTenuringThreshold of 31, though the 
default will remain at the current value of 15.

This includes the same change to the 32-bit version, which would close 
bug 6719225 as well.  In that case, the hash field in the header is 
affected, losing one bit (25 bits -> 24), so I have asked for review 
from hotspot-runtime-dev as well as gc-dev.

Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
Testing:  JPRT and reference server performance tests

Notes:
Contrary to what earlier notes in the JBS entry said, this does not 
require stronger alignment for the JavaThread structure for when biased 
locking stores that pointer in the header.   The JavaThread* was already 
being aligned 1 power of 2 more strongly than it needed to be, so there 
was an unused bit that could be stolen.

In the 32-bit version, it does require taking one bit from the hash 
field, which goes from 25 to 24 bits.  This is something I'd especially 
like feedback on.  Running reference server performance tests, I saw no 
impact from this change.  We *could* make this change 64-bit-only, and 
leave the age field at 4 bits for the 32-bit version.  If we did so, we 
could also decrease the alignment required for the JavaThread* to 512 
from the current 1024.

The comment changes imply that the bits available for the JavaThread* 
have been reduced by 1, and that the alignment is now stronger, but 
neither is true.  The comments have been corrected to match the 
alignment that was already enforced.

Three tests needed to be corrected to match the new limits.  These check 
the maximum valid values, what value represents NeverTenure, and so on.

Thanks,
Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150212/d80f4ab9/attachment.htm>


More information about the hotspot-gc-dev mailing list