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
