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

[Mandy Chung]

On 10/9/2013 1:19 AM, Aleksey Shipilev wrote:
> Hi Mandy,
>
> On 10/09/2013 11:46 AM, Mandy Chung wrote:
>> 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.
> Hm, this is the first time I hear about this contract, is it really
> specified somewhere? Or, is it the informal status quo? Because it feels
> remarkably as the implementation detail. I don't think users should be
> exposed to the distinction between launcher and VM anyway.

The spec of RuntimeMXBean.getInputArguments says:
    Returns the input arguments passed to the Java virtual machine which 
does not include the arguments to the main method.

It didn't say it can't include invalid VM options but they are just not 
VM options and the hotspot implementation will exit if they were passed 
to the VM.

Our java launcher is one implementation that loads and initialize the 
hotspot VM but there are other custom launchers out there that can call 
JNI_CreateJavaVM to load and initialize a JVM.

>
>> -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().
> Okay, let me state the intent cleaner. The tools I maintain (jmh and
> jcstress are notable examples) need to start exactly the same VM with
> exactly the same "java" options. How would you propose to do this?

You want to exec another process with the same command-line options to 
the java launcher (or augmenting with additional ones).   Your proposed 
fix will only work with this implementation and the application is 
launched by the java launcher.  In other words, your tools wouldn't 
support any other launcher implementation that may launch different 
VMs.  Maybe you are only interested in our JDK implementation.

> Recovering the command line by parsing getVmName() uses (unstable)
> stringly conventions to detect the running VM, and also pushes me to
> maintain the list of all possible VMs in the detection code.
>
> RuntimeMXBean.getInputArguments() omits some launcher options, but it is
> fixable to expose these options to the user, no stringly parsing is
> required on user side.
>
> Do you see any better option?

I no longer work in this area and don't have any suggestion at the 
moment.   Although parsing of VM name is not ideal, I suggest it as a 
workaround for now and give the serviceability team time to look into 
this to address your request.

Mandy
>
> -Aleksey.