RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
david.holmes at oracle.com
Fri Feb 13 02:54:55 UTC 2015
If you are potentially messing with the (identity) hash of all Java
objects in the 32-bit case then this needs a broader discussion eg on
core-libs-dev (cc'd) as this will impact end-user code the most!
The rest seems okay but I'm still mulling over it. :)
On 13/02/2015 6:14 AM, Tom Benson wrote:
> 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
> 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.
More information about the hotspot-runtime-dev