Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
On 02/13/2015 08:47 AM, Peter Levart wrote: On 02/13/2015 03:54 AM, 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! As I understand, this will make identity hashCode have 2^24 instead of 2^25 distinct values on 32 bit architectures, right? This will mostly affect java.util.IdentityHashMap performance (and any use of objects that don't override hashCode in other hashCode-based Maps). IHM has a maximum capacity of 2^29 (key, value) slots. Performance will start to degrade sooner - at sizes 2^24 / 1.5 (~10M) instead of 2^25 / 1.5 (~20M) entries. In other words, it approximately doubles the probability of a collision for tables with more than 10 million keys. It's a sure thing that some applications out there will see measurable slowdowns. So the justification needed here is whether these slowdowns are more than compensated by the benefits of adding another age bit. This seems hard to carry out, but the fallback plan of adding age bit only on 64bit platforms that don't impact hash bits sounds completely safe. -Doug
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
On 02/13/2015 03:54 AM, 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.
Hi,
As I understand, this will make identity hashCode have 2^24 instead of
2^25 distinct values on 32 bit architectures, right? This will mostly
affect java.util.IdentityHashMap performance (and any use of objects
that don't override hashCode in other hashCode-based Maps). IHM has a
maximum capacity of 2^29 (key, value) slots. Performance will start to
degrade sooner - at sizes 2^24 / 1.5 (~10M) instead of 2^25 / 1.5
(~20M) entries.
IHM has the following hashCode - array slot index mapping function:
/**
* Returns index for Object x.
*/
private static int hash(Object x, int length) {
int h = System.identityHashCode(x);
// Multiply by -127, and left-shift to use least bit as part of
hash
return ((h 1) - (h 8)) (length - 1);
}
Left-shift is added because keys are located at even indexes and
associated values are at odd indexes in the same array. So the function
to map hashCode to ordinal key index is actually:
(h - (h 7)) (capacity - 1)
where capacity is a power of two = 2^29, which means that it is
necessary that 24 hash bits from Object header be mapped to lower 24
bits of Object.hashCode(). Object.hashCode() in range 0..2^24-1 should
still be enough to address the whole range of 2^29 capacity table given
the above mapping function.
So the question is, how frequent are IdentityHashMap(s) with 10M
entries or any other HashMaps with keys that don't override
Object.hashCode().
Here's an JMH (http://openjdk.java.net/projects/code-tools/jmh/)
micro-benchmark you can use to measure the impact of change on
IdentityHashMap:
http://cr.openjdk.java.net/~plevart/misc/IHMBench/IHMBench.java
by default it creates an IdentityHashMap with size of 2^24 entries. This
is where the performance difference is expected to start to be different
between 24bit vs. 25bit hash codes. You can also try to use larger (up
to 28) 'log2size' parameter, but you might want to increate -Xmx too in
this case.
Regards, Peter
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
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
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
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
On 02/13/2015 04:37 PM, Tom Benson 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 Hi Tom, This is just my uneducated thinking... I can imagine that with G1 collector this is more complicated, but with standard young-gen collector where there are 2 survivor spaces, couldn't they be labeled A and B and when MaxTenuringThreshold 15, the Object's age be incremented only when it is moved in one direction A - B (and not when it is moved B - A). For MaxTenuringThreshold of say 24, it would be moved to OldGen when age 24/2 then. The resolution of MaxTenuringThreshold 15 could only be specified in steps of 2 then (16, 18, 20, ... 30). I guess the movement of young objects among survivor regions in G1 is not so regular (so that you could label half of survivor regions with A and the other half with B and objects would always move from A - B or B - A and never A - A or B - B), right? Regards, Peter 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
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
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... Peter 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
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
Hi, On 2015-02-13 16:37, Tom Benson 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. This sounds like a good approach in my view. I think we can leave the age at 4 bits. In my view the main issue with the aging is that our heuristics for adjusting the tenuring threshold are not always reliable. Sometimes the threshold gets stuck at the max value etc. I prefer to close these bug reports as suggested above and if we want to improve the tenuring we should work on the heuristics instead. Thanks for digging these bug reports up, Tom! We should probably have brought them up for discussion and closing them a long time ago. Thanks, Bengt 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
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
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
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
Hi, Note that not taking this bit for the age field would open the door to reducing the alignment of the JavaThread*. It's the fact that there was already an unclaimed bit there (in the 64-bit version) that made the age size increase seem more reasonable. However, I'd propose not changing that, either, at least for the 64-bit version, so that when someone finally claims the bit it doesn't need to be undone. For the 32-bit version, it's less clear cut, but I'd still lean toward leaving it as is. Tom On 2/13/2015 11:37 AM, Bengt Rutisson wrote: Hi, On 2015-02-13 16:37, Tom Benson 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. This sounds like a good approach in my view. I think we can leave the age at 4 bits. In my view the main issue with the aging is that our heuristics for adjusting the tenuring threshold are not always reliable. Sometimes the threshold gets stuck at the max value etc. I prefer to close these bug reports as suggested above and if we want to improve the tenuring we should work on the heuristics instead. Thanks for digging these bug reports up, Tom! We should probably have brought them up for discussion and closing them a long time ago. Thanks, Bengt However, if there are supporters of a larger MaxTenuringThreshold lurking, I'd like to hear their point of view as well. Thanks, Tom
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
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
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
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
Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
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
