RFE: Add compressed oops to VM info string

Krystal Mok rednaxelafx at gmail.com
Mon Nov 14 03:22:51 PST 2011 

Hi all,

(Sorry for replying so late. I was attending a conference last Friday, and
didn't have reliable network connection until today.)

A thanks to everyone in the discussion.

I wasn't sure whether it's appropriate or not to mention other JVM impls on
this list, but, just for reference, this is the version string from J9:

$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr8fp1-20100624_01(SR8 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64
jvmxa6460sr8ifx-20100609_59383 (JIT enabled, AOT enabled)
J9VM - 20100609_059383
JIT  - r9_20100401_15339ifx2
GC   - 20100308_AA)
JCL  - 20100624_01
$ java -Xcompressedrefs -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr8fp1-20100624_01(SR8 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64
jvmxa6460sr8ifx-20100609_59383 (JIT enabled, AOT enabled)
J9VM - 20100609_059383
JIT  - r9_20100401_15339ifx2
GC   - 20100308_AA_CMPRSS)
JCL  - 20100624_01

Notice the GC line; "CMPRSS" shows this VM is using compressed references.
It probably makes more sense to show this info with J9 because it's another
set of VM binaries when -Xcompressedrefs is given to the launcher.

It's much more verbose than HotSpot's version string. Not arguing for this
kind of verbose style, it's just that I was looking for an easy way to get
people tell me what VM configuration they were using.

But yes, the most of you are right, the VM version string is a public
interface and shouldn't be changed without a very good reason.

@Mandy
Thanks for mentioning -XshowSettings. That looks like a good place to add
these kind of verbose / internal information.
I'll make another patch based on -XshowSettings or -Xinternalversion.

@Coleen
I've been using PrintCompressedOopsMode to get the compressed oops mode for
some time. Too bad once the mode is calculated (and printed), it's thrown
away, leaving only the base and shift values. Sometimes it might be useful
to keep the mode; one of my extensions to HotSpot actually needed it to
check for VM argument consistency, and I had to duplicate
PrintCompressedOopsMode code to get it done.

@David
Printing flags isn't good enough in some scenarios.
Take jmap -heap for example. HeapSummary prints out a few flags of
interest, but it can be misleading for people who don't know that not all
flags are in effect all the time.
In [1], MaxNewSize shows "17592186044415 MB", and OldSize shows "5439488
(5.1875MB)". Neither of these values correspond to the actual heap stats;
they just act as a hint to let ergonomics make the decision.
PrintFlagsFinal won't do any good in this kind of scenario (and
PrintCommandLineFlags won't show anything).

Regards,
Kris Mok

[1]: https://gist.github.com/1363195

On Sat, Nov 12, 2011 at 7:53 AM, Srinivas Ramakrishna <ysr1729 at gmail.com>wrote:

> +1 to David's (and others') suggestion:-
>
> I agree that +PrintFlagsFinal makes this less subjective and more uniform.
>
> -- ramki
>
>
> On Thu, Nov 10, 2011 at 1:31 PM, David Holmes <david.holmes at oracle.com>wrote:
>
>> In case I didn't mention it earlier there is also -Xinternalversion which
>> might be extended this way.
>>
>> But personally I think printing the flags is the way to go, and if the
>> desired flags are not printed then that is a RFE for the print-flags
>> options.
>>
>> David
>>
>>
>> On 11/11/2011 4:02 AM, Mandy Chung wrote:
>>
>>> FWIW. Kumar added an internal option -XshowSettings to the launcher in
>>> JDK 7 to print various VM and java settings. This could be a potential
>>> place to include "compressed oops" and other VM ergonomic setting in. It
>>> takes an optional suboption "all, vm, properties, locale".
>>>
>>> $ java -XshowSettings:vm
>>>
>>> VM settings:
>>> Stack Size: 320.00K
>>> Max. Heap Size (Estimated): 910.00M
>>> Ergonomics Machine Class: server
>>> Using VM: Java HotSpot(TM) Server VM
>>>
>>> [snip..]
>>>
>>> java -XshowSettings -version doesn't print the additional information. I
>>> haven't spent time looking into the reason why.
>>>
>>> Mandy
>>>
>>> On 11/10/11 08:01, Paul Hohensee wrote:
>>>
>>>> I don't think the version string is the place for dumping ergo
>>>> decision results,
>>>> rather I agree with David Holmes and Joe that PrintFlagsFinal,
>>>> PrintCommandLineFlags,
>>>> or some other switch should be used. We shouldn't have "mixed mode",
>>>> etc. in the
>>>> string either, but given that they're there we're kinda stuck with them.
>>>>
>>>> The reason we have "Server" and "Client" (and "Embedded, btw) is to
>>>> distinguish
>>>> builds that are statically different. Tiered got folded into Server
>>>> awhile ago, which
>>>> is why it's no longer mentioned in the version string.
>>>>
>>>> Changing the version string is a non-trivial thing to do: it has to go
>>>> through
>>>> an approval process because it's a supported public interface. There
>>>> are, e.g.,
>>>> quite a few version string parsers out there that wouldn't take kindly
>>>> to change.
>>>>
>>>> Paul
>>>>
>>>> On 11/10/11 8:18 AM, Volker Simonis wrote:
>>>>
>>>>> +1 from me
>>>>>
>>>>> On Thu, Nov 10, 2011 at 12:44 PM, Christian Thalinger
>>>>> <christian.thalinger at oracle.**com <christian.thalinger at oracle.com>>
>>>>> wrote:
>>>>>
>>>>>> On Nov 10, 2011, at 12:16 PM, Volker Simonis wrote:
>>>>>>
>>>>>>  Hi Kris,
>>>>>>>
>>>>>>> first I want to say that I like and support your enhancement request.
>>>>>>>
>>>>>>> However once we do this, if would suggest printing other
>>>>>>> information as well.
>>>>>>> Particularly the fact if we're using tiered compilation comes to my
>>>>>>> mind here.
>>>>>>>
>>>>>>> I would therefore suggest to use a less verbose "compressed oops"
>>>>>>> string and also
>>>>>>> print the concrete compressed oops mode that's actually used
>>>>>>> (unscaled, zerobased, heapbased).
>>>>>>> This information may be particularly usefull because it may change
>>>>>>> depending on the users heap setting
>>>>>>> and the current system memory situation.
>>>>>>>
>>>>>>> So finally, we could use something like:
>>>>>>>
>>>>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode,
>>>>>>> tiered,
>>>>>>> compr-oops=unscaled)
>>>>>>>
>>>>>> Honestly I don't know what it takes to change that string since it's
>>>>>> a public known option. But my personal opinion is: print the most
>>>>>> important runtime settings like JIT mode, GC used, compressed oops
>>>>>> mode. Something along these lines:
>>>>>>
>>>>>> Java HotSpot(TM) Server VM (build 23.0-b03, mixed mode, tiered,
>>>>>> serial gc, zerobased coops)
>>>>>>
>>>>>> Just my two cents...
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>>  For such a version string, it would be probably better to construct
>>>>>>> the string on the fly, otherwise
>>>>>>> the 'info_strs' struct you are currently using may become too big.
>>>>>>>
>>>>>>> What are your opinions?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Volker
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 10, 2011 at 8:54 AM, Krystal Mok<rednaxelafx at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>> I'd like to propose to add "compressed oops" to the VM info
>>>>>>>> string, so that
>>>>>>>> people using "java -version" can get a better understanding of the
>>>>>>>> ergonomics of the VM.
>>>>>>>> I've posted a patch [1], against hsx20's master. The files
>>>>>>>> modified are
>>>>>>>> still pretty much the same on hotspot-main's master.
>>>>>>>> With the patch applied, "java -version" may show:
>>>>>>>> OpenJDK 64-Bit Server VM (build 20.0-b11-internal, mixed mode,
>>>>>>>> compressed
>>>>>>>> oops)
>>>>>>>> and what used to work still works:
>>>>>>>> OpenJDK Client VM (build 20.0-b11-internal, mixed mode, sharing)
>>>>>>>> P.S. Alibaba (Taobao)'s OCA is submitted already, still waiting
>>>>>>>> for approval
>>>>>>>> from Oracle.
>>>>>>>> Regards,
>>>>>>>> Kris Mok
>>>>>>>> Software Engineer, Taobao (http://www.taobao.com)
>>>>>>>> [1]: https://gist.github.com/**1354299<https://gist.github.com/1354299>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111114/8fbbfc50/attachment.html

More information about the hotspot-dev mailing list