RFE: Add compressed oops to VM info string
Krystal Mok
rednaxelafx at gmail.com
Mon Nov 14 17:50:12 PST 2011
HI David,
The jmap -heap example is also printing some of the VM flags as part of the
heap summary.
The problem is, the flags printed can be misleading, because some of them
can be different than the actual value used by the actual heap, due to the
way ergonomics works now. The MaxNewSize and OldSize flags in the example
shows exactly that.
I've had colleagues asking me why they're getting a young gen of size
"17592186044415 MB", and it took a while to explain to them that it's just
a hint to ergonomics, and not the actual value used.
For people who do know the internals, though, you're right that the flags
(+ some of the HSPERFDATA counters for things that are not a flag) already
give a lot of clues of what's going on. It's just not so obvious for
normals users, and some kind of summary would be nice.
Regards,
Kris Mok
On Tue, Nov 15, 2011 at 9:10 AM, David Holmes <david.holmes at oracle.com>wrote:
> On 14/11/2011 9:22 PM, Krystal Mok wrote:
>
>> @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).
>>
>
> As I said if the print-flags option isn't showing the compressed-oops flag
> settings then that should be fixed.
>
> Sorry I don't understand the connection to your jmap -heap example.
>
> David
> -----
>
> Regards,
>> Kris Mok
>>
>> [1]: https://gist.github.com/**1363195 <https://gist.github.com/1363195>
>>
>> On Sat, Nov 12, 2011 at 7:53 AM, Srinivas Ramakrishna <ysr1729 at gmail.com
>> <mailto: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 <mailto:david.holmes at oracle.**com<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
>>
>> <mailto:christian.thalinger@**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
>> <mailto: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>
>> <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/20111115/6ed59980/attachment-0001.html
More information about the hotspot-dev
mailing list