RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64
Aleksey Shipilev
aleksey.shipilev at oracle.com
Wed Oct 9 01:19:17 PDT 2013
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.
> -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.
More information about the serviceability-dev
mailing list