Hi Tom, Some background on some observations and strategies folks have tended to take wrt GC tuning.
With both Parallel GC and CMS GC, a common approach by folks tuning GC and heap sizes is to employ a strategy of promoting as few objects as possible from young generation to old generation. In other words, keep live objects in young generation as long as possible. This is where the max tenuring threshold comes in. If you have the ability to have higher object ages, those live objects can slosh around between survivor spaces for a longer time / higher age and have a higher probability of becoming unreachable before getting promoted to old generation. Once they are in old generation, (as you know) with Parallel GC it is a bit more expensive to collect them. With CMS, promoting fewer objects to old generation implies less chance for old generation fragmentation. However, with G1 GC, we have the ability to incrementally collect old generation and incrementally collecting old generation does not have the pain points that Parallel GC and CMS GC carry with them. So the approach of trying to avoid object promotion is not as useful with G1. Hence, the value of having a higher max tenuring threshold is not as important with G1. And, with G1 expected to one day replace Parallel GC and CMS GC, whenever that might be ;-) … well, you get the picture. To summarize, I suspect folks who are using Parallel GC or CMS GC could probably take advantage of a higher max tenuring threshold. But, in G1 I have not seen that having a higher max tenuring threshold as being nearly as useful. There may be others in the community who do GC tuning on a daily basis who may be able to offer their observations and experience too. Fwiw, from my perspective I am ok with the suggestion in your note below of closing this as “evolution of the JVM since the time the age field was reduced has revealed potentially more valuable uses for the bit”. hths, charlie > On Feb 13, 2015, at 9: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 >>>> >
