Kumar Srinivasan said the following on 11/12/10 13:11:
Is the purpose here to report what command-line options were used or
to report what particular settings are in effect? If the former then
you do not need any defaults for the "not set" case. If the latter
then you should really defer this to the VM itself for the "VM
options", because as it stands:
Right we need to defer it to the VM, jdk7++ ? I will file an RFE to do
this.
I'd rather see the VM print these things itself - one of the -XX options
likely already prints this and a lot more - rather than providing an
additional interface for the launcher to query the VM. In which case
just drop this from the current scope of work and leave it for the VM.
- if -Xmx is not set then Runtime.maxMemory() is not equivalent, so
you are misleading the user (And why not report -Xms?)
No one beat me up on Xms so much as Xmx or max memory.:-)
That aside it is inconsistent to report one but not the other.
As for memory, IIRC I compared the values that
java.lang.management.MemoryUsage.max
which reports the same value as I get here.
That's fine as long as you don't claim that what you are reporting is
the -Xmx value when it is not.
I will explain some of this in the help document, and maybe put a note
next to one of these
values such as 985M (approx.)
- if -Xss is not set the resulting value is not an OS default but a VM
default
In the case of windows the VM has no preference so the launcher defaults
back to the OS,
but if the VM has a pref. then that would be reported, usually *nixes.
My point remains that saying "OS defaults" is inaccurate in general, and
saying "VM or OS default" is unhelpful - it contains zero information so
better to say nothing, or get the real ThreadStackSize from the VM
- ServerClassMachine() does not take into account -Xint possibility
(and will need updating for Tiered compilation)
Absolutely when that becomes a reality.
You overlooked the -Xint part. I believe you will report "client" when
-Xint is specified.
I'd be tempted to just drop the "VM options" part of this, unless you
are going to make a call into the VM to obtain them.
I think I want to have it and put in the necessary VM hooks at a later
stage. It would be
good to get this in and get more feedback and enhance/evolve it in a
future release.
I think the VM values should only come from the VM. The current proposal
is ad-hoc, incomplete and inaccurate. (But that pretty much sums up the
state of all our flags anyway: -foo vs -Xfoo vs -XX:foo :( )
David
Thanks
Kumar
David
Kumar Srinivasan said the following on 11/12/10 07:56:
Hi All,
Please review the following:
http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/
This will print all the known settings/properties/locales
supported and known to Java, this has been a long standing request.
A sample output attached below.
Note: the -X option specifically is being used so we can evolve this
option
and add more useful information, in future versions of java.
Thanks
Kumar
