RFR 8030011: Update Hotspot version string output

[David Holmes]

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
>>>
>