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 >>
