Re: RFR 8030011: Update Hotspot version string output
Thanks Vladimir
Alejandro
On 4/23/2014 11:53 AM, Vladimir Kozlov wrote:
Looks good.
Thanks,
Vladimir
On 4/22/14 7:32 PM, Alejandro E Murillo wrote:
On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:
On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is
still
used to set JVM's version string and not JDK's version.
Next assert message is not consistent with previous messages which
use
vm, I think it should be vm here too:
DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build
number));
we do not have hotspot build number anymore, so I think we should not
mention hotspot build numberls
Can we simple say wrong build number?
sounds good!
So you don't want update build number in make/*_version files? ;)
Yes, I see in your example of JPRT build VM does not have build number
anymore.
it's gone!
Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.
I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html
No, I mean next code should encode micro version too:
unsigned int Abstract_VM_Version::jvm_version() {
return ((Abstract_VM_Version::vm_major_version() 0xFF) 24) |
((Abstract_VM_Version::vm_minor_version() 0xFF) 16) |
+ ((Abstract_VM_Version::vm_micro_version() 0xFF) 8) |
(Abstract_VM_Version::vm_build_number() 0xFF);
}
you are right. I recall having added that earlier :(
it's back int the webrev
Use corresponding test in jdk for testing of these changes:
jdk/test/sun/misc/Version/Version.java
yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions
Good.
jvm.h: Next comment is not accurate:
+/* VM version string: JDK version string */
If we build VM separately (for example, in JPRT) VM version will not
be JDK version in which VM is installed. It will take numbers either
from passed make parameters or from make/hotspot_version. I think it
should say:
+/* VM version string follows the JDK release version naming
convention
+ * major.minor.micro-bxx[-identifier][-debug_flavor]
Based on your examples [-identifier][-debug_flavor] is still used
so it should be reflected in the comment.
Let me make that explicit.
Don't remove next comments from vm_version.cpp but fix it (follow
the
JDK release):
-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// major_ver.minor_ver-bnn[-identifier][-debug_target]
ok
You did not show default VM version example when VM is built locally
by engineer.
It will be similar to the hotspot only jprt build. There will be a
mismatch,
I tested by dropping the resulting libjvm into a promoted build,
so it
looks like this:
java version 1.9.0-ea
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed
mode)
okay
Please test that correct version string is constructed when you build
VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
Haven't tested that, thanks for pointing that out.
thank you
Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:
-# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
HOTSPOT_BUILD_VERSION
see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
let me check that again
I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:
-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since
the JDK version string
sometimes might have time stamps, it may affect ccache, that's why at
some point they
separated the options for vm_version.cpp from the options for other
components. See this
comment on vm,make:
# This is VERY important! The version define must only be supplied to
vm_version.o
# If not, ccache will not re-use the cache at all, since the version
string might contain
# a time and date.
I was concern that it will not be passed into nested make so that, for
example, buildtree.make will not get it.
I see. I don't think it's needed
I think I incorporated all the changes David, John and you suggested and
started some sanity testing;
Here's is the latest webrev:
http://cr.openjdk.java.net/~amurillo/9/8030011/
Please review (don't forget to refresh each file on your browser) and
let me know if I missed anything.
Re: RFR 8030011: Update Hotspot version string output
Alejandro E Murillo (alejandro.muri...@oracle.com) wrote: ... I think I incorporated all the changes David, John and you suggested and started some sanity testing; Here's is the latest webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Please review (don't forget to refresh each file on your browser) and let me know if I missed anything. thanks guys! Looks good. Might be nice to shorten the rest of the assert messages in vm_version.cpp to match the one for the build number, e.g., bad major version). -John
Re: RFR 8030011: Update Hotspot version string output
On 4/24/2014 2:52 PM, John Coomes wrote: Alejandro E Murillo (alejandro.muri...@oracle.com) wrote: ... I think I incorporated all the changes David, John and you suggested and started some sanity testing; Here's is the latest webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Please review (don't forget to refresh each file on your browser) and let me know if I missed anything. thanks guys! Looks good. Might be nice to shorten the rest of the assert messages in vm_version.cpp to match the one for the build number, e.g., bad major version). -John Will do, thanks John -- Alejandro
Re: RFR 8030011: Update Hotspot version string output
Looks good.
Thanks,
Vladimir
On 4/22/14 7:32 PM, Alejandro E Murillo wrote:
On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:
On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.
Next assert message is not consistent with previous messages which use
vm, I think it should be vm here too:
DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build
number));
we do not have hotspot build number anymore, so I think we should not
mention hotspot build numberls
Can we simple say wrong build number?
sounds good!
So you don't want update build number in make/*_version files? ;)
Yes, I see in your example of JPRT build VM does not have build number
anymore.
it's gone!
Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.
I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html
No, I mean next code should encode micro version too:
unsigned int Abstract_VM_Version::jvm_version() {
return ((Abstract_VM_Version::vm_major_version() 0xFF) 24) |
((Abstract_VM_Version::vm_minor_version() 0xFF) 16) |
+ ((Abstract_VM_Version::vm_micro_version() 0xFF) 8) |
(Abstract_VM_Version::vm_build_number() 0xFF);
}
you are right. I recall having added that earlier :(
it's back int the webrev
Use corresponding test in jdk for testing of these changes:
jdk/test/sun/misc/Version/Version.java
yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions
Good.
jvm.h: Next comment is not accurate:
+/* VM version string: JDK version string */
If we build VM separately (for example, in JPRT) VM version will not
be JDK version in which VM is installed. It will take numbers either
from passed make parameters or from make/hotspot_version. I think it
should say:
+/* VM version string follows the JDK release version naming
convention
+ * major.minor.micro-bxx[-identifier][-debug_flavor]
Based on your examples [-identifier][-debug_flavor] is still used
so it should be reflected in the comment.
Let me make that explicit.
Don't remove next comments from vm_version.cpp but fix it (follow the
JDK release):
-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// major_ver.minor_ver-bnn[-identifier][-debug_target]
ok
You did not show default VM version example when VM is built locally
by engineer.
It will be similar to the hotspot only jprt build. There will be a
mismatch,
I tested by dropping the resulting libjvm into a promoted build, so it
looks like this:
java version 1.9.0-ea
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed
mode)
okay
Please test that correct version string is constructed when you build
VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
Haven't tested that, thanks for pointing that out.
thank you
Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:
-# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
HOTSPOT_BUILD_VERSION
see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
let me check that again
I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:
-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since
the JDK version string
sometimes might have time stamps, it may affect ccache, that's why at
some point they
separated the options for vm_version.cpp from the options for other
components. See this
comment on vm,make:
# This is VERY important! The version define must only be supplied to
vm_version.o
# If not, ccache will not re-use the cache at all, since the version
string might contain
# a time and date.
I was concern that it will not be passed into nested make so that, for
example, buildtree.make will not get it.
I see. I don't think it's needed
I think I incorporated all the changes David, John and you suggested and
started some sanity testing;
Here's is the latest webrev:
http://cr.openjdk.java.net/~amurillo/9/8030011/
Please review (don't forget to refresh each file on your browser) and
let me know if I missed anything.
thanks guys!
Re: RFR 8030011: Update Hotspot version string output
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote: Hi Alejandro, I don't think we need to rename make/hotspot_version file. It is still used to set JVM's version string and not JDK's version. Next should be 2014 (I think David pointed it too but there is no new webrev): HOTSPOT_VM_COPYRIGHT=Copyright 2013 correct. I haven't changed that yet If you pass major, micro etc numbers to avoid parsing you need to verify that constructed from them string is equal to passed HOTSPOT_RELEASE_VERSION. yes, there's a test for that, which is run when I submit a full jprt job. Next assert message is not consistent with previous messages which use vm, I think it should be vm here too: DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build number)); we do not have hotspot build number anymore, so I think we should not mention hotspot build numberls Abstract_VM_Version::jvm_version() should include micro version. See JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in jdk/src/share/javavm/export/jvm.h. I added that here, is that what you are referring? http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html Use corresponding test in jdk for testing of these changes: jdk/test/sun/misc/Version/Version.java yeah, I run that test as part of jprt full builds, That test handles both JDK and Hotspot express versions jvm.h: Next comment is not accurate: +/* VM version string: JDK version string */ If we build VM separately (for example, in JPRT) VM version will not be JDK version in which VM is installed. It will take numbers either from passed make parameters or from make/hotspot_version. I think it should say: +/* VM version string follows the JDK release version naming convention + * major.minor.micro-bxx[-identifier][-debug_flavor] Based on your examples [-identifier][-debug_flavor] is still used so it should be reflected in the comment. Let me make that explicit. Don't remove next comments from vm_version.cpp but fix it (follow the JDK release): -// HOTSPOT_RELEASE_VERSION must follow the release version naming convention -// major_ver.minor_ver-bnn[-identifier][-debug_target] ok You did not show default VM version example when VM is built locally by engineer. It will be similar to the hotspot only jprt build. There will be a mismatch, I tested by dropping the resulting libjvm into a promoted build, so it looks like this: java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b01) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed mode) Please test that correct version string is constructed when you build VM using make/build.sh, for example 'sh make/build.sh debug LP64=1' Haven't tested that, thanks for pointing that out. Next comment change in buildtree.make is not correct because HOTSPOT_RELEASE_VERSION make parameter does not include HOTSPOT_BUILD_VERSION: -# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07) +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus HOTSPOT_BUILD_VERSION see JPRT logs where HOTSPOT_BUILD_VERSION is set separately. let me check that again I think next change in make/defs.make is not safe (removing make parameter) due to complexity of our builds: -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION) I checked the code, and HOTSPOT_RELEASE_VERSION is only used in vm_version.cpp, so I think is fine to remove it. Note that if we keep it there, since the JDK version string sometimes might have time stamps, it may affect ccache, that's why at some point they separated the options for vm_version.cpp from the options for other components. See this comment on vm,make: # This is VERY important! The version define must only be supplied to vm_version.o # If not, ccache will not re-use the cache at all, since the version string might contain # a time and date. I know that windows build is mess. Please verify it carefully. For example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but build.make uses them: JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER) That was a typo. Note that I changed the left handside, so they were incorrectly reassigning those. The places were JDK_MINOR_VER is used, the value is read from jdk_version (formerly hotspot_version) Thanks a lot for the feedback! Alejandro Regards, Vladimir On 4/21/14 10:13 AM, Alejandro E Murillo wrote: On 4/18/2014 6:50 PM, John Coomes wrote: Alejandro E Murillo (alejandro.muri...@oracle.com) wrote: Please review this change to make the hotspot related output produced by java -version match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo
Re: RFR 8030011: Update Hotspot version string output
On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.
Next assert message is not consistent with previous messages which use
vm, I think it should be vm here too:
DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build
number));
we do not have hotspot build number anymore, so I think we should not
mention hotspot build numberls
Can we simple say wrong build number?
So you don't want update build number in make/*_version files? ;)
Yes, I see in your example of JPRT build VM does not have build number
anymore.
Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.
I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html
No, I mean next code should encode micro version too:
unsigned int Abstract_VM_Version::jvm_version() {
return ((Abstract_VM_Version::vm_major_version() 0xFF) 24) |
((Abstract_VM_Version::vm_minor_version() 0xFF) 16) |
+ ((Abstract_VM_Version::vm_micro_version() 0xFF) 8) |
(Abstract_VM_Version::vm_build_number() 0xFF);
}
Use corresponding test in jdk for testing of these changes:
jdk/test/sun/misc/Version/Version.java
yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions
Good.
jvm.h: Next comment is not accurate:
+/* VM version string: JDK version string */
If we build VM separately (for example, in JPRT) VM version will not
be JDK version in which VM is installed. It will take numbers either
from passed make parameters or from make/hotspot_version. I think it
should say:
+/* VM version string follows the JDK release version naming
convention
+ * major.minor.micro-bxx[-identifier][-debug_flavor]
Based on your examples [-identifier][-debug_flavor] is still used
so it should be reflected in the comment.
Let me make that explicit.
Don't remove next comments from vm_version.cpp but fix it (follow the
JDK release):
-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// major_ver.minor_ver-bnn[-identifier][-debug_target]
ok
You did not show default VM version example when VM is built locally
by engineer.
It will be similar to the hotspot only jprt build. There will be a
mismatch,
I tested by dropping the resulting libjvm into a promoted build, so it
looks like this:
java version 1.9.0-ea
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed mode)
okay
Please test that correct version string is constructed when you build
VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
Haven't tested that, thanks for pointing that out.
thank you
Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:
-# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
HOTSPOT_BUILD_VERSION
see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
let me check that again
I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:
-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since
the JDK version string
sometimes might have time stamps, it may affect ccache, that's why at
some point they
separated the options for vm_version.cpp from the options for other
components. See this
comment on vm,make:
# This is VERY important! The version define must only be supplied to
vm_version.o
# If not, ccache will not re-use the cache at all, since the version
string might contain
# a time and date.
I was concern that it will not be passed into nested make so that, for
example, buildtree.make will not get it.
I know that windows build is mess. Please verify it carefully. For
example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but
build.make uses them:
JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER)
That was a typo. Note that I changed the left handside, so they were
incorrectly reassigning those.
The places were JDK_MINOR_VER is used, the value is read from
jdk_version (formerly hotspot_version)
Okay.
Thanks,
Vladimir
Thanks a lot for the feedback!
Alejandro
Regards,
Vladimir
On 4/21/14 10:13 AM, Alejandro E Murillo wrote:
On 4/18/2014 6:50 PM, John Coomes wrote:
Alejandro
Re: RFR 8030011: Update Hotspot version string output
On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:
On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.
Next assert message is not consistent with previous messages which use
vm, I think it should be vm here too:
DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build
number));
we do not have hotspot build number anymore, so I think we should not
mention hotspot build numberls
Can we simple say wrong build number?
sounds good!
So you don't want update build number in make/*_version files? ;)
Yes, I see in your example of JPRT build VM does not have build number
anymore.
it's gone!
Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.
I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html
No, I mean next code should encode micro version too:
unsigned int Abstract_VM_Version::jvm_version() {
return ((Abstract_VM_Version::vm_major_version() 0xFF) 24) |
((Abstract_VM_Version::vm_minor_version() 0xFF) 16) |
+ ((Abstract_VM_Version::vm_micro_version() 0xFF) 8) |
(Abstract_VM_Version::vm_build_number() 0xFF);
}
you are right. I recall having added that earlier :(
it's back int the webrev
Use corresponding test in jdk for testing of these changes:
jdk/test/sun/misc/Version/Version.java
yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions
Good.
jvm.h: Next comment is not accurate:
+/* VM version string: JDK version string */
If we build VM separately (for example, in JPRT) VM version will not
be JDK version in which VM is installed. It will take numbers either
from passed make parameters or from make/hotspot_version. I think it
should say:
+/* VM version string follows the JDK release version naming
convention
+ * major.minor.micro-bxx[-identifier][-debug_flavor]
Based on your examples [-identifier][-debug_flavor] is still used
so it should be reflected in the comment.
Let me make that explicit.
Don't remove next comments from vm_version.cpp but fix it (follow the
JDK release):
-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// major_ver.minor_ver-bnn[-identifier][-debug_target]
ok
You did not show default VM version example when VM is built locally
by engineer.
It will be similar to the hotspot only jprt build. There will be a
mismatch,
I tested by dropping the resulting libjvm into a promoted build, so it
looks like this:
java version 1.9.0-ea
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed
mode)
okay
Please test that correct version string is constructed when you build
VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
Haven't tested that, thanks for pointing that out.
thank you
Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:
-# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
HOTSPOT_BUILD_VERSION
see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
let me check that again
I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:
-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since
the JDK version string
sometimes might have time stamps, it may affect ccache, that's why at
some point they
separated the options for vm_version.cpp from the options for other
components. See this
comment on vm,make:
# This is VERY important! The version define must only be supplied to
vm_version.o
# If not, ccache will not re-use the cache at all, since the version
string might contain
# a time and date.
I was concern that it will not be passed into nested make so that, for
example, buildtree.make will not get it.
I see. I don't think it's needed
I think I incorporated all the changes David, John and you suggested and
started some sanity testing;
Here's is the latest webrev:
http://cr.openjdk.java.net/~amurillo/9/8030011/
Please review (don't forget to refresh each file on your browser) and
let me know if I missed anything.
thanks guys!
--
Alejandro
Re: RFR 8030011: Update Hotspot version string output
On 4/18/2014 6:50 PM, John Coomes wrote:
Alejandro E Murillo (alejandro.muri...@oracle.com) wrote:
Please review this change to make the hotspot related output produced by
java -version
match the corresponding JDK output:
webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
Note that we initially wanted to obtain more information from the repo
being built and add
it to the hotspot version output, but that will require changes in the
JPRT, so
we have decided to split the change in 2 bugs. One to make the version match
(above webrev) and another one, an RFE, to add additional information
extracted from the repo.
Generally looks good, but I agree with David that the long lines
should be wrapped, and it might even be clearer to separate them into
two variables, e.g.,
JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ \
-DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ \
... other defs ...
VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ \
-DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ \
$(JDK_VERSION_DEFS)
Also the change to this part of vm.make differs between at least the
solaris version and the linux version (didn't check bsd or windows).
Please make them all consistent.
Note that in the current version of vm_version.cpp, there is no error
checking in product mode,
I was suggested to make that explicit.
I like the additional error checking. I think you could eliminate the
4 copies of similar code with a function that does the checks and sets
the field, e.g.,
void set_version_field(int * version_field, const char * version_str,
const char * const assert_msg) {
if (version_str != NULL ...) {
DEBUG_ONLY(assert_digits(version_str, assert_msg));
*version_field = atoi(version_str);
}
}
-John
Thanks John,
working on adding these changes and sanity testing
Thanks
--
Alejandro
Re: RFR 8030011: Update Hotspot version string output
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.
Next should be 2014 (I think David pointed it too but there is no new
webrev): HOTSPOT_VM_COPYRIGHT=Copyright 2013
If you pass major, micro etc numbers to avoid parsing you need to verify
that constructed from them string is equal to passed
HOTSPOT_RELEASE_VERSION.
Next assert message is not consistent with previous messages which use
vm, I think it should be vm here too:
DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build
number));
Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.
Use corresponding test in jdk for testing of these changes:
jdk/test/sun/misc/Version/Version.java
jvm.h: Next comment is not accurate:
+/* VM version string: JDK version string */
If we build VM separately (for example, in JPRT) VM version will not be
JDK version in which VM is installed. It will take numbers either from
passed make parameters or from make/hotspot_version. I think it should say:
+/* VM version string follows the JDK release version naming convention
+ * major.minor.micro-bxx[-identifier][-debug_flavor]
Based on your examples [-identifier][-debug_flavor] is still used so
it should be reflected in the comment.
Don't remove next comments from vm_version.cpp but fix it (follow the
JDK release):
-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// major_ver.minor_ver-bnn[-identifier][-debug_target]
You did not show default VM version example when VM is built locally by
engineer.
Please test that correct version string is constructed when you build VM
using make/build.sh, for example 'sh make/build.sh debug LP64=1'
Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:
-# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus HOTSPOT_BUILD_VERSION
see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:
-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I know that windows build is mess. Please verify it carefully. For
example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but
build.make uses them:
JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER)
Regards,
Vladimir
On 4/21/14 10:13 AM, Alejandro E Murillo wrote:
On 4/18/2014 6:50 PM, John Coomes wrote:
Alejandro E Murillo (alejandro.muri...@oracle.com) wrote:
Please review this change to make the hotspot related output produced by
java -version
match the corresponding JDK output:
webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
Note that we initially wanted to obtain more information from the repo
being built and add
it to the hotspot version output, but that will require changes in the
JPRT, so
we have decided to split the change in 2 bugs. One to make the
version match
(above webrev) and another one, an RFE, to add additional information
extracted from the repo.
Generally looks good, but I agree with David that the long lines
should be wrapped, and it might even be clearer to separate them into
two variables, e.g.,
JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ \
-DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ \
... other defs ...
VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ \
-DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ \
$(JDK_VERSION_DEFS)
Also the change to this part of vm.make differs between at least the
solaris version and the linux version (didn't check bsd or windows).
Please make them all consistent.
Note that in the current version of vm_version.cpp, there is no error
checking in product mode,
I was suggested to make that explicit.
I like the additional error checking. I think you could eliminate the
4 copies of similar code with a function that does the checks and sets
the field, e.g.,
void set_version_field(int * version_field, const char *
version_str,
const char * const assert_msg) {
if (version_str != NULL ...) {
DEBUG_ONLY(assert_digits(version_str, assert_msg));
*version_field = atoi(version_str);
}
}
-John
Thanks John,
working on adding these changes and sanity testing
Thanks
Re: RFR 8030011: Update Hotspot version string output
Alejandro E Murillo (alejandro.muri...@oracle.com) wrote:
Please review this change to make the hotspot related output produced by
java -version
match the corresponding JDK output:
webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
Note that we initially wanted to obtain more information from the repo
being built and add
it to the hotspot version output, but that will require changes in the
JPRT, so
we have decided to split the change in 2 bugs. One to make the version match
(above webrev) and another one, an RFE, to add additional information
extracted from the repo.
Generally looks good, but I agree with David that the long lines
should be wrapped, and it might even be clearer to separate them into
two variables, e.g.,
JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ \
-DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ \
... other defs ...
VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ \
-DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ \
$(JDK_VERSION_DEFS)
Also the change to this part of vm.make differs between at least the
solaris version and the linux version (didn't check bsd or windows).
Please make them all consistent.
Note that in the current version of vm_version.cpp, there is no error
checking in product mode,
I was suggested to make that explicit.
I like the additional error checking. I think you could eliminate the
4 copies of similar code with a function that does the checks and sets
the field, e.g.,
void set_version_field(int * version_field, const char * version_str,
const char * const assert_msg) {
if (version_str != NULL ...) {
DEBUG_ONLY(assert_digits(version_str, assert_msg));
*version_field = atoi(version_str);
}
}
-John
Re: RFR 8030011: Update Hotspot version string output
On 4/10/2014 8:11 PM, David Holmes wrote: On 11/04/2014 1:42 AM, Alejandro E Murillo wrote: Hi David, thanks for the feedback, see below On 4/9/2014 8:38 PM, David Holmes wrote: Hi Alejandro, Given we have to maintain the JDK version information in two places (top level repo and hotspot repo) wouldn't it have been simpler to keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set the major/minor/build values to match those of the JDK version? The file is still used, just renamed as only jdk info is in there. HOTSPOT_RELEASE_VERSION was also kept, we just don't get the major,minor,micro and build number from it anymore, mainly it is now set very similar to the JDK_RELEASE_VERSION (plus other values), and that format it's not fixed as it used to be for hotspot express. Those values (major,minor,micro and build number) are already defined in the makefiles, so we just pass them to vm_version.cpp, so no more parsing in it. I still think the overall changes could have been much smaller but okay. The change actually is not that big, what happens is that due to the makefile structure the exact same change has to be replicated on each platform. Then, some of the changes themselves are actually comment changes, to remove references to the hsx hs version, and/or removal of lines of code that had been removed in some platform (Solaris) but not in others; also renaming some macros to better reflect what they are for. I also fixed some typos on macros names that were incorrect already, like these: http://cr.openjdk.java.net/~amurillo/9/8030011/make/windows/makefiles/defs.make.wdiff.html In a nutshell I just added the ability to get major,minor,micro and build number available to vm_version.cpp, in addition to hotspot_release_version, so that we don't have parse that to obtain those. And of course, adding additional testing of those values that is minimal right now. The other changes are related to now having to handle the micro_version, which was ignored with the old hotspot_version, but that has to be done regardless of how the values were obtained. The change is actually simple, compared to understanding how the makefiles work and how vm_version receives the values. Alejandro Thanks, David - That aside, in jdk_version file hotspot copyright should now be 2014 will fix that */vm.make: This line is way too long. ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ -DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ -DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ -DJDK_MICRO_VERSION=\$(JDK_MICRO_VERSION)\ -DJDK_BUILD_NUMBER=\$(JDK_BUILD_NUMBER)\ ok Not clear why we suddenly need defines for all the component pieces either. You could have kept the HS_XXX variables, just adding the micro part. as mentioned above, the micro part was actually added to HOTSPOT_RELEASE_VERSION, we just don't get those values by parsing it, so we just pass those values to the vm_version.cpp, since they are already defined in the makefiles. The format of the JDK version is not that fixed. Thanks Alejandro David On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: Please review this change to make the hotspot related output produced by java -version match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo being built and add it to the hotspot version output, but that will require changes in the JPRT, so we have decided to split the change in 2 bugs. One to make the version match (above webrev) and another one, an RFE, to add additional information extracted from the repo. Note that in the current version of vm_version.cpp, there is no error checking in product mode, I was suggested to make that explicit. Release Engineering did some testing and I also ran several cases with full and just hotspot JPRT builds. Here is a summary of how the new output compares to the old one: (1) Release Engineering builds (9-dev): from jdk9-dev build: java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (2) Release Engineering builds (jdk9): java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (3) JPRT Full builds: java version 1.9.0-internal # Java(TM) SE Runtime
Re: RFR 8030011: Update Hotspot version string output
Hi David, thanks for the feedback, see below On 4/9/2014 8:38 PM, David Holmes wrote: Hi Alejandro, Given we have to maintain the JDK version information in two places (top level repo and hotspot repo) wouldn't it have been simpler to keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set the major/minor/build values to match those of the JDK version? The file is still used, just renamed as only jdk info is in there. HOTSPOT_RELEASE_VERSION was also kept, we just don't get the major,minor,micro and build number from it anymore, mainly it is now set very similar to the JDK_RELEASE_VERSION (plus other values), and that format it's not fixed as it used to be for hotspot express. Those values (major,minor,micro and build number) are already defined in the makefiles, so we just pass them to vm_version.cpp, so no more parsing in it. That aside, in jdk_version file hotspot copyright should now be 2014 will fix that */vm.make: This line is way too long. ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ -DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ -DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ -DJDK_MICRO_VERSION=\$(JDK_MICRO_VERSION)\ -DJDK_BUILD_NUMBER=\$(JDK_BUILD_NUMBER)\ ok Not clear why we suddenly need defines for all the component pieces either. You could have kept the HS_XXX variables, just adding the micro part. as mentioned above, the micro part was actually added to HOTSPOT_RELEASE_VERSION, we just don't get those values by parsing it, so we just pass those values to the vm_version.cpp, since they are already defined in the makefiles. The format of the JDK version is not that fixed. Thanks Alejandro David On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: Please review this change to make the hotspot related output produced by java -version match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo being built and add it to the hotspot version output, but that will require changes in the JPRT, so we have decided to split the change in 2 bugs. One to make the version match (above webrev) and another one, an RFE, to add additional information extracted from the repo. Note that in the current version of vm_version.cpp, there is no error checking in product mode, I was suggested to make that explicit. Release Engineering did some testing and I also ran several cases with full and just hotspot JPRT builds. Here is a summary of how the new output compares to the old one: (1) Release Engineering builds (9-dev): from jdk9-dev build: java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (2) Release Engineering builds (jdk9): java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (3) JPRT Full builds: java version 1.9.0-internal # Java(TM) SE Runtime Environment (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode) (4) JPRT hotspot only builds: java version 1.9.0-ea-fastdebug # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed mode) in this one the built VM is inserted into a promoted build bundle, since we do not have the JDK build number info in the hotspot repo, we can't match the build number in the JDK portion. With the RFE mentioned above, we can extract the build info from the repo and add it to the hotspot portion. I want to mention, that this may change once the new JDK version change is implemented but we don't know when that will be implemented yet, so we need to go ahead with this to get rid of the old hotspot express output. And most of these changes will still have to be done anyways BTW, john Coomes and Dan Daugherty provided feedback in some pieces of this webrev, but I need full reviews now. Thanks -- Alejandro
Re: RFR 8030011: Update Hotspot version string output
On 11/04/2014 1:42 AM, Alejandro E Murillo wrote: Hi David, thanks for the feedback, see below On 4/9/2014 8:38 PM, David Holmes wrote: Hi Alejandro, Given we have to maintain the JDK version information in two places (top level repo and hotspot repo) wouldn't it have been simpler to keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set the major/minor/build values to match those of the JDK version? The file is still used, just renamed as only jdk info is in there. HOTSPOT_RELEASE_VERSION was also kept, we just don't get the major,minor,micro and build number from it anymore, mainly it is now set very similar to the JDK_RELEASE_VERSION (plus other values), and that format it's not fixed as it used to be for hotspot express. Those values (major,minor,micro and build number) are already defined in the makefiles, so we just pass them to vm_version.cpp, so no more parsing in it. I still think the overall changes could have been much smaller but okay. Thanks, David - That aside, in jdk_version file hotspot copyright should now be 2014 will fix that */vm.make: This line is way too long. ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ -DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ -DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ -DJDK_MICRO_VERSION=\$(JDK_MICRO_VERSION)\ -DJDK_BUILD_NUMBER=\$(JDK_BUILD_NUMBER)\ ok Not clear why we suddenly need defines for all the component pieces either. You could have kept the HS_XXX variables, just adding the micro part. as mentioned above, the micro part was actually added to HOTSPOT_RELEASE_VERSION, we just don't get those values by parsing it, so we just pass those values to the vm_version.cpp, since they are already defined in the makefiles. The format of the JDK version is not that fixed. Thanks Alejandro David On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: Please review this change to make the hotspot related output produced by java -version match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo being built and add it to the hotspot version output, but that will require changes in the JPRT, so we have decided to split the change in 2 bugs. One to make the version match (above webrev) and another one, an RFE, to add additional information extracted from the repo. Note that in the current version of vm_version.cpp, there is no error checking in product mode, I was suggested to make that explicit. Release Engineering did some testing and I also ran several cases with full and just hotspot JPRT builds. Here is a summary of how the new output compares to the old one: (1) Release Engineering builds (9-dev): from jdk9-dev build: java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (2) Release Engineering builds (jdk9): java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (3) JPRT Full builds: java version 1.9.0-internal # Java(TM) SE Runtime Environment (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode) (4) JPRT hotspot only builds: java version 1.9.0-ea-fastdebug # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed mode) in this one the built VM is inserted into a promoted build bundle, since we do not have the JDK build number info in the hotspot repo, we can't match the build number in the JDK portion. With the RFE mentioned above, we can extract the build info from the repo and add it to the hotspot portion. I want to mention, that this may change once the new JDK version change is implemented but we don't know when that will be implemented yet, so we need to go ahead with this to get rid of the old hotspot express output. And most of these changes will still have to be done anyways BTW, john Coomes and Dan Daugherty provided feedback in some pieces of this webrev, but I need full reviews now. Thanks
Re: RFR 8030011: Update Hotspot version string output
Hi Alejandro, Given we have to maintain the JDK version information in two places (top level repo and hotspot repo) wouldn't it have been simpler to keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set the major/minor/build values to match those of the JDK version? That aside, in jdk_version file hotspot copyright should now be 2014 */vm.make: This line is way too long. ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ -DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ -DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ -DJDK_MICRO_VERSION=\$(JDK_MICRO_VERSION)\ -DJDK_BUILD_NUMBER=\$(JDK_BUILD_NUMBER)\ Not clear why we suddenly need defines for all the component pieces either. You could have kept the HS_XXX variables, just adding the micro part. David On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: Please review this change to make the hotspot related output produced by java -version match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo being built and add it to the hotspot version output, but that will require changes in the JPRT, so we have decided to split the change in 2 bugs. One to make the version match (above webrev) and another one, an RFE, to add additional information extracted from the repo. Note that in the current version of vm_version.cpp, there is no error checking in product mode, I was suggested to make that explicit. Release Engineering did some testing and I also ran several cases with full and just hotspot JPRT builds. Here is a summary of how the new output compares to the old one: (1) Release Engineering builds (9-dev): from jdk9-dev build: java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (2) Release Engineering builds (jdk9): java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (3) JPRT Full builds: java version 1.9.0-internal # Java(TM) SE Runtime Environment (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode) (4) JPRT hotspot only builds: java version 1.9.0-ea-fastdebug # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed mode) in this one the built VM is inserted into a promoted build bundle, since we do not have the JDK build number info in the hotspot repo, we can't match the build number in the JDK portion. With the RFE mentioned above, we can extract the build info from the repo and add it to the hotspot portion. I want to mention, that this may change once the new JDK version change is implemented but we don't know when that will be implemented yet, so we need to go ahead with this to get rid of the old hotspot express output. And most of these changes will still have to be done anyways BTW, john Coomes and Dan Daugherty provided feedback in some pieces of this webrev, but I need full reviews now. Thanks
