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.
