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.
