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.ben...@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 >>>> >>>> >
