Hi Aleksey,

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. -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().

Moving forward, I can foresee different VMs being requested which can
not be guessed that easily. Think -XXaltjvm= or some other black magic
in launcher. Because of that, I think more generic solution (like the
variant being proposed) is more viable.

A different VM should have a name that can easily differentiate from other implementation. The only thing I can imagine missing for such a future launcher is the pathname if specified in the command-line. I would suggest to revisit this when such a launcher option is added and determine what API is needed.

Mandy

On 10/8/2013 7:39 AM, Aleksey Shipilev wrote:
Yes, I can see that reasoning.

I have the opposite perspective though: I think it is the matter of user
experience, RuntimeMXBean should not care about the launcher/VM
distinction, since what user "perceives" is the JVM launched via "java".
Segregating the launcher and "pure" VM options seems to be exposing the
implementation detail. Thus, this fix actually covers up that glitch.

-Aleksey.

On 10/08/2013 10:16 AM, David Holmes wrote:
As I wrote in the bug report I have reservations about this as these are
launcher options not VM options. Plus with the dropping of 32-bit
Solaris the -d32/-d64 part will be moot. That leaves the VM "mode" -
client, server, minimal or whatever might happened to be defined via
jvm.cfg (-server might actually run client VM).

David

On 3/10/2013 11:40 PM, Aleksey Shipilev wrote:
Hi,

Please take a look at the potential fix for:
    https://bugs.openjdk.java.net/browse/JDK-8025700

The webrev is here:
    http://cr.openjdk.java.net/~shade/8025700/webrev.01/

Rationale: when doing the Java tools which need to replicate the VM
launch, e.g. fork the JVM with the same set of command line options, we
need the exact command line. Otherwise we miss the significant part of
configuration, which confuses people. So far we miss "-server",
"-client", "-d32", and "-d64" options from there. I have seen troubles
with jmh and jcstress stemming from this very issue.

Testing:
    - new jtreg test, works fine on Linux x86_64; (I can run other
platforms as long as the fix approach is sound)
    - jdk/test/tools/launcher jtreg tests on Linux x86_64

Thanks,
-Aleksey


Reply via email to