RFR 8030011: Update Hotspot version string output

Fri Apr 11 19:20:58 UTC 2014

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