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.
The issue I am trying to solve is to provide 1 well documented flag to
get the user
all the *important* settings in java that he/she needs to know. It is
next to impossible
to keep track of all the undocumented -XX flags that the VM supports.
[ this is a can of worms]
- 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.
I will add this later.
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.
Ok I will change/remove the flag hints.
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
It is difficult to get this on windows, this is going back to the first
issue, either we get
the VM to print this using some api or have this information sent back
to the launcher
so that it can be printed via showSettings flag. For now I will remove
the field if I cannot
determine it.
- 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.
On what class machine ? a server class ? in which case it reports
"server" for me.
The ServerClassMachine is set depending on the # of processors and amount
of RAM on the system. If you are asking me to fix the launcher
ergonomics that is
beyond the scope of this work.
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.
It is incomplete!, that is why I have the disclaimer and proposed it as
"-X" flag.
So that we can evolve this flag in future releases, and use jdk7 to get
the feedback
from users on what they would like to see for settings.
(But that pretty much sums up the state of all our flags anyway: -foo
vs -Xfoo vs -XX:foo :( )
Yeh I know and I rest my case for this flag. ;-)
This is exactly why we need one interface to bring the whole Java
setting story together.
We cannot tell our users/support personnel, SQE etc. to use different
flags to get the
Java and VM settings.
Thanks
Kumar
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
