RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64

[Mandy Chung]

Hi Aleksey,

Like David said, -client/-server and -d32/-d64 are launcher option but 
not VM options.  RuntimeMXBean.getInputArguments() returns the arguments 
passed to the VM which is created via the JNI_CreateJavaVM API.   
-client/-server is the java launcher option that determines which VM to 
load and initialize and it's not an option passed to the JVM.   In 
addition, -client/-server is actually not a valid option to the hotspot 
VM.  Instead, you can find out if it's a server/client/minimal VM from 
getVmName().

> Moving forward, I can foresee different VMs being requested which can
> not be guessed that easily. Think -XXaltjvm= or some other black magic
> in launcher. Because of that, I think more generic solution (like the
> variant being proposed) is more viable.

A different VM should have a name that can easily differentiate from 
other implementation.    The only thing I can imagine missing for such a 
future launcher is the pathname if specified in the command-line.  I 
would suggest to revisit this when such a launcher option is added and 
determine what API is needed.

Mandy

On 10/8/2013 7:39 AM, Aleksey Shipilev wrote:
> Yes, I can see that reasoning.
>
> I have the opposite perspective though: I think it is the matter of user
> experience, RuntimeMXBean should not care about the launcher/VM
> distinction, since what user "perceives" is the JVM launched via "java".
> Segregating the launcher and "pure" VM options seems to be exposing the
> implementation detail. Thus, this fix actually covers up that glitch.
>
> -Aleksey.
>
> On 10/08/2013 10:16 AM, David Holmes wrote:
>> As I wrote in the bug report I have reservations about this as these are
>> launcher options not VM options. Plus with the dropping of 32-bit
>> Solaris the -d32/-d64 part will be moot. That leaves the VM "mode" -
>> client, server, minimal or whatever might happened to be defined via
>> jvm.cfg (-server might actually run client VM).
>>
>> David
>>
>> On 3/10/2013 11:40 PM, Aleksey Shipilev wrote:
>>> Hi,
>>>
>>> Please take a look at the potential fix for:
>>>     https://bugs.openjdk.java.net/browse/JDK-8025700
>>>
>>> The webrev is here:
>>>     http://cr.openjdk.java.net/~shade/8025700/webrev.01/
>>>
>>> Rationale: when doing the Java tools which need to replicate the VM
>>> launch, e.g. fork the JVM with the same set of command line options, we
>>> need the exact command line. Otherwise we miss the significant part of
>>> configuration, which confuses people. So far we miss "-server",
>>> "-client", "-d32", and "-d64" options from there. I have seen troubles
>>> with jmh and jcstress stemming from this very issue.
>>>
>>> Testing:
>>>     - new jtreg test, works fine on Linux x86_64; (I can run other
>>> platforms as long as the fix approach is sound)
>>>     - jdk/test/tools/launcher jtreg tests on Linux x86_64
>>>
>>> Thanks,
>>> -Aleksey
>>>