<div dir="ltr">Dear Tom,<div><br></div><div>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.</div><div><br></div><div>Carsten</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 10:37 AM, Tom Benson <span dir="ltr"><<a href="mailto:tom.benson@oracle.com" target="_blank">tom.benson@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
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."<br>
<br>
However, if there are supporters of a larger MaxTenuringThreshold lurking, I'd like to hear their point of view as well.<br>
Thanks,<br>
Tom<div class="HOEnZb"><div class="h5"><br>
<br>
On 2/13/2015 9:42 AM, Karen Kinnear wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Seconded. For the hash code, talk to Coleen and ask her who did the work in core libs recently.<br>
<br>
In addition, those bits are fiercely sought after - we have other things we would like to do with any available bits and I am<br>
not convinced this is more valuable. We just resisted using one for the jdk9 frozen arrays although we might want one to mark<br>
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<br>
a design where we need to distinguish reference objects from value types underneath a common object header for jdk10).<br>
<br>
So - hmmm.<br>
<br>
thanks,<br>
Karen<br>
<br>
On Feb 12, 2015, at 9:54 PM, David Holmes wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Tom,<br>
<br>
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!<br>
<br>
The rest seems okay but I'm still mulling over it. :)<br>
<br>
Thanks,<br>
David H.<br>
<br>
On 13/02/2015 6:14 AM, Tom Benson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
I need reviewers and a commit sponsor for changes for bug 6764713, which<br>
will increase the size of the age field in an object header from 4 bits<br>
to 5. This will allow a maximum MaxTenuringThreshold of 31, though the<br>
default will remain at the current value of 15.<br>
<br>
This includes the same change to the 32-bit version, which would close<br>
bug 6719225 as well. In that case, the hash field in the header is<br>
affected, losing one bit (25 bits -> 24), so I have asked for review<br>
from hotspot-runtime-dev as well as gc-dev.<br>
<br>
Webrev: <a href="http://cr.openjdk.java.net/~jprovino/6764713/webrev.00" target="_blank">http://cr.openjdk.java.net/~<u></u>jprovino/6764713/webrev.00</a><br>
JBS bug: <a href="https://bugs.openjdk.java.net/browse/JDK-6764713" target="_blank">https://bugs.openjdk.java.net/<u></u>browse/JDK-6764713</a><br>
Testing: JPRT and reference server performance tests<br>
<br>
Notes:<br>
Contrary to what earlier notes in the JBS entry said, this does not<br>
require stronger alignment for the JavaThread structure for when biased<br>
locking stores that pointer in the header. The JavaThread* was already<br>
being aligned 1 power of 2 more strongly than it needed to be, so there<br>
was an unused bit that could be stolen.<br>
<br>
In the 32-bit version, it does require taking one bit from the hash<br>
field, which goes from 25 to 24 bits. This is something I'd especially<br>
like feedback on. Running reference server performance tests, I saw no<br>
impact from this change. We *could* make this change 64-bit-only, and<br>
leave the age field at 4 bits for the 32-bit version. If we did so, we<br>
could also decrease the alignment required for the JavaThread* to 512<br>
from the current 1024.<br>
<br>
The comment changes imply that the bits available for the JavaThread*<br>
have been reduced by 1, and that the alignment is now stronger, but<br>
neither is true. The comments have been corrected to match the<br>
alignment that was already enforced.<br>
<br>
Three tests needed to be corrected to match the new limits. These check<br>
the maximum valid values, what value represents NeverTenure, and so on.<br>
<br>
Thanks,<br>
Tom<br>
<br>
</blockquote></blockquote></blockquote>
<br>
</div></div></blockquote></div><br></div>