[8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result

Severin Gehwolf sgehwolf at redhat.com
Thu May 7 15:09:05 UTC 2020


Hi,

Please review this OpenJDK 8u fix for an issue where the update version
as configured via --with-update-version=XXX might overflow in internal
JDK structures and thus, will get reported wrong. In particular, only 1
byte is being reserved for the update versions internally. That is, it
works fine up to a configured update version of 255 (2^8 - 1). We've
passed that in OpenJDK 8u with the 8u262 cycle currently in EA. Hence,
we are now seeing this issue.

Bug: https://bugs.openjdk.java.net/browse/JDK-8244548
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/02/
testing: Linux tier 1

The proposed fix is to extend the update_version field in
jdk_version_info from 8 to 16 bit and to use 16 bit of the jvm_version
integer in jvm_version_info. Thus, the new upper bound for update
version number is 2^16-1 => 65535 which should be sufficient. I don't
think OpenJDK 8u will live that long ;-)

jvm_version_info.jvm_version currently holds this quadruplet:

Most significant 8 bits => major version, followed by 8 bits => minor
version, followed by 8 bits => micro version, followed by 8 bits =>
build version. Note that JVM minor version represents the update
version as passed in via configure and the micro version is currently
not used (always 0). See vm_version.cpp lines 100-102 where only major,
minor and build number are ever been set. Knowing this, we can still
preserve the same behavior after patch by defining JVM_VERSION_MICRO to
0 for any version.

For jdk_version_info the fix is simpler, since the update_version is a
separate field for which I've extended it to 16 bit. Andrew Brygin
suggested to reduce the reserved1 field from currently 16 bit to 8 bit
since we are extending update_version by 8 bits, thus making the whole
structure grow. I'm not sure reducing reserved1 to 8 bits so as to not
grow the structure would be necessary, but I'd be happy to do so if
there is such consensus.

Thoughts?

Thanks,
Severin



More information about the core-libs-dev mailing list