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

[Carsten Varming]

Dear Tom,

If you want very large MaxTenuringThresholds, then you could add an option
to reinterpret the value of the four bits to be a power of 2. One way is to
only bump the age from i to i+1 when the gc count is divisible by 2^i. You
lose granularity and precision, but gain some very large ages.

Carsten

On Fri, Feb 13, 2015 at 10:37 AM, Tom Benson <tom.benson at oracle.com> wrote:

> Hi,
> Based on comments here and elsewhere on possible future uses for this
> unused bit (in the 64-bit version), I'm more inclined to close both 6764713
> and 6719225 with no change.  With a comment along the lines of "evolution
> of the JVM since the time the age field was reduced has revealed
> potentially more valuable uses of the bit."
>
> However, if there are supporters of a larger MaxTenuringThreshold lurking,
> I'd like to hear their point of view as well.
> Thanks,
> Tom
>
>
> On 2/13/2015 9:42 AM, Karen Kinnear wrote:
>
>> Seconded. For the hash code, talk to Coleen and ask her who did the work
>> in core libs recently.
>>
>> In addition, those bits are fiercely sought after - we have other things
>> we would like to do with any available bits and I am
>> not convinced this is more valuable. We just resisted using one for the
>> jdk9 frozen arrays although we might want one to mark
>> immutable objects or value types (yes, today those don't have an identity
>> hash but I am not yet convinced that we won't have
>> a design where we need to distinguish reference objects from value types
>> underneath a common object header for jdk10).
>>
>> So - hmmm.
>>
>> thanks,
>> Karen
>>
>> On Feb 12, 2015, at 9:54 PM, David Holmes wrote:
>>
>>  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
>>>>
>>>>
>