RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
varming at gmail.com
Fri Feb 13 16:13:56 UTC 2015
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.
On Fri, Feb 13, 2015 at 10:37 AM, Tom Benson <tom.benson at oracle.com> wrote:
> 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.
> 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.
>> 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. :)
>>> David H.
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev