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

Peter Levart peter.levart at gmail.com
Fri Feb 13 16:55:04 UTC 2015

On 02/13/2015 05:13 PM, Carsten Varming wrote:
> 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

GC count, yes. Clever.

Or, 4 bit value 'x' could be reinterpreted as being multiplied by 
constant 'k', computed from MaxTenuringThreshold:

k = 1 + (MaxTenuringThreshold >> 4);
0 <= MaxTenuringThreshold <= 15: k = 1
16 <= MaxTenuringThreshold <= 31: k = 2
32 <= MaxTenuringThreshold <= 47: k = 3
48 <= MaxTenuringThreshold <= 63: k = 4

...then increment 'x' when GC count is divisible by 'k'. When 'x' > 
MaxTenuringThreshold / k, object is OLD...


> 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

More information about the hotspot-gc-dev mailing list