Please review -XshowSettings a java launcher option.
kumar.x.srinivasan at oracle.com
Fri Nov 12 07:16:12 PST 2010
>>> 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
>> 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
>>> - 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
So that we can evolve this flag in future releases, and use jdk7 to get
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.
>>> Kumar Srinivasan said the following on 11/12/10 07:56:
>>>> Hi All,
>>>> Please review the following:
>>>> 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.
More information about the core-libs-dev