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

David Holmes david.holmes at oracle.com
Fri Feb 13 02:54:55 UTC 2015


Hi Tom,

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. :)

Thanks,
David H.

On 13/02/2015 6:14 AM, Tom Benson wrote:
> 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
>



More information about the hotspot-gc-dev mailing list