Please review -XshowSettings a java launcher option.

David Holmes David.Holmes at oracle.com
Fri Nov 12 04:59:35 UTC 2010


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
>>>
>>>
>>>
> 



More information about the core-libs-dev mailing list