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

[David Holmes]

On 9/10/2013 6:19 PM, 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.

It is our launcher and the use of -client/-server/-d32/-d64 which is the 
implementation detail! So if you want the launcher args (which you do 
because you intend to execute the same launcher) then the launcher has 
to make them available. To that end I think the best long term solution 
is to have a well-defined property that the launcher can set (if it 
chooses) to hold launcher arguments that the launcher wishes to show the 
VM. A public variation of the sun.java.command property. The 
implementation should be quite simple and the CCC request would not be 
that involved.

It is definitely unfortunate that there is no easy way to determine 
which VM you are running, in a manner that allows you to launch a 
similar one. This impacts a lot of our testing as well - many tests will 
launch the default VM (based on jvm.cfg and ergonomics) instead of the 
VM intended to be tested!

David
-----

>> -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?
>
> 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?
>
> -Aleksey.
>