Hi David,
Please review simple fix for JDK-8180202, recall we hard coded "server",
this is incorrect because the function CheckJvmType will determin
the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by
-XXaltjvm. IMO all this needs to be cleaned up when jvm.cfg is removed.
So this original change was wrong:
! const char *jvmtypeUsed = ((bitsWanted == 64) &&
(strcmp(jvmtype, "client") == 0)) ? "server" : jvmtype;
! const char *jvmtypeUsed = "server";
because jvmType might still be something other than "server"? Not sure
how but okay.
However I don't see the connection to -XXaltjvm as that should be
setting a full path itself and not relying on jvmType within the
well-known path ??
Ah, please see
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/51214dadd48f/src/java.base/macosx/native/libjli/java_md_macosx.c#l420
What is happening is if XXaltjvm contains a slash then it treats it as a
path,
ex: -XXaltjvm /tmp/myvm
if not then jvmtype, and uses it choose the VM variant, the latter seems to
be an override for jvm.cfg, ex: -XXaltjvm minimal
Not sure of the historical background, all this needs some cleanup, and
removing jvm.cfg will help clean some of this mess up.
Hope that clarifies.
Kumar
Thanks
Kumar
PS: please also approve the removal of the test from the internal
ProblemList.txt
Ok.
Thanks,
David
diff in the JBS issue.
diff --git a/src/java.base/macosx/native/libjli/java_md_macosx.c
b/src/java.base/macosx/native/libjli/java_md_macosx.c
--- a/src/java.base/macosx/native/libjli/java_md_macosx.c
+++ b/src/java.base/macosx/native/libjli/java_md_macosx.c
@@ -424,7 +424,7 @@
* macosx client library is built thin, i386 only.
* 64 bit client requests must load server library
*/
- JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/server/" JVM_DLL,
jrepath);
+ JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
jrepath, jvmtype);
}
JLI_TraceLauncher("Does `%s' exist ... ", jvmpath);
