RFE: Add compressed oops to VM info string
David Holmes
david.holmes at oracle.com
Mon Nov 14 18:03:02 PST 2011
On 15/11/2011 11:50 AM, Krystal Mok wrote:
> 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.
Okay but I don't see a connection to the original subject. If you print
(or use) flags you need to understand what they mean.
David
-----
> 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
> <mailto: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>
> <mailto: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>
> <mailto:david.holmes at oracle.__com
> <mailto: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 at __oracle.com
> <mailto: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>
> <mailto: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>>
>
>
>
>
>
>
More information about the hotspot-dev
mailing list