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

[Srinivas Ramakrishna]

Hi Tom,

Perhaps you misunderstood the comments in the jira (although my memory is
foggy now, so many years later): the comments (and the diffs), IIRC, stated
that the age bits can go up to 6 (in the 64-bit jvm) without changing the
JavaThread* alignment (which may or may not have been different at the time
the comments were written). And that any larger number of bits for age
would require wider alignment. As you stated for the 32-bit case, yes,
you'd be forced to steal a bit from somewhere.

I am traveling at the moment with very limited internet access, so haven't
looked at yr diffs, although I might have better connectivity next week.
-- ramki

On Fri, Feb 13, 2015 at 1:44 AM, Tom Benson <tom.benson at oracle.com> 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
>
>