@@ -633,6 +633,22 @@
return jvmtype;
}
+/*
+ * This is called if the jvmtype returned by CheckJvmType above
+ * didn't exist. In this case if it was the default VM and we
+ * selected the server vm we will allow it to use the client vm
+ * instead.
+ */
+char *
+GetAltJvmType(char *jvmtype)
+{
+ if ((knownVMs[0].flag == VM_IF_SERVER_CLASS) &&
+ (jvmtype == knownVMs[0].server_class+1)) {
+ return knownVMs[0].name+1;
+ }
+ return NULL;
+}
+
/* copied from HotSpot function "atomll()" */
static int
parse_size(const char *s, jlong *result) {
@@ -164,6 +164,7 @@
*/
jint ReadKnownVMs(const char *jvmcfg, jboolean speculative);
char *CheckJvmType(int *argc, char ***argv, jboolean speculative);
+char *GetAltJvmType(char *jvmtype);
void AddOption(char *str, void *info);
enum ergo_policy {
@@ -31,5 +31,6 @@
# "-XXaltjvm=<jvm_dir>" option, but that too is unsupported
# and may not be available in a future release.
#
--client KNOWN
--server IF_SERVER_CLASS KNOWN
+-client IF_SERVER_CLASS -server
+-server KNOWN
+-minimal KNOWN
@@ -465,8 +465,17 @@
}
if (!GetJVMPath(jrepath, jvmtype, jvmpath, so_jvmpath, arch, 0 )) {
- JLI_ReportErrorMessage(CFG_ERROR8, jvmtype, jvmpath);
- exit(4);
+ char *altjvmtype = GetAltJvmType(jvmtype);
+ jboolean found = JNI_FALSE;
+ if (altjvmtype) {
+ jvmtype = altjvmtype;
+ jvmpath[0] = '\0';
+ found = GetJVMPath(jrepath, jvmtype, jvmpath, so_jvmpath, arch, 0) != NULL;
+ }
+ if (!found) {
+ JLI_ReportErrorMessage(CFG_ERROR8, jvmtype, jvmpath);
+ exit(4);
+ }
}
/*
* we seem to have everything we need, so without further ado
Hi, The following patch fixes the problems seen by Andrew Haley when doing a native server build. The first change is to update the jvm.cfg file which was broken in any case. The previous vsn read -client KNOWN -server IF_SERVER_CLASS KNOWN This is broken both syntactically and semantically. Syntactically from the description in jdk8/jdk/src/share/bin/java.c the syntax of a predicateLine is * predicateLine := flag "IF_SERVER_CLASS" flag EOL (where flag is a '-' followed by a vm name) The semantics of the predicateLine is as follows * - if the flag appears as the first flag on a predicateLine, and * the machine on which you are running passes the predicate indicated, * then the identifier of the second flag is used as the name of the JVM, * otherwise the identifier of the first flag is used as the name of the JVM. * If no flag is given on the command line, the first vmLine of the jvm.cfg * file determines the name of the JVM. * PredicateLines are only interpreted on first vmLine of a jvm.cfg file, * since they only make sense if someone hasn't specified the name of the * JVM on the command line. I have changed the jvm.cfg to read -client IF_SERVER_CLASS -server -server KNOWN -minimal KNOWN (this is simply copied from i586 jvm.cfg, which is the same as the arm and sparc jvm.cfg) >>>>>>>>>>> Note that this changes the default VM to be -server <<<<<<<<<<<<<<< However this does not fully fix the problems seen by Andrew Haley. It merely transfers the error from the server build to the client build. IE. Now, with the new jvm.cfg you will get the following error when doing a native client build. Error: missing 'server' JVM at ........... The remaining changes to java.c, java.h and java_md_solinux.c work around the problem as follows. If we selected a server VM based on the IF_SERVER_CLASS predicate and it turns out that in fact the server VM is missing, then we revert to using the client VM. Note that this only happens if no vm is specified on the command line. If a vm is specified on the command line and that vm does not exist an error will always be generated. This has to be a run time test rather than a compile time build option in order to allow for a new VM to be plugged in (IE. we cannot tell whether a server vm exists at compile time based on whether we are doing a client/server build because a server VM can always be added later to a client build). So why is this a problem for aarch64 but not for 64bit x86 (amd64). The jvm.cfg for amd64 specifies -server KNOWN -client IGNORE IE. If you specify -client on the command line, it ignores it and runs the server compiler anyway. I am assuming that we do not want this behaviour and that we do in fact want to be able to run the client compiler on aarch64. If this is not the case and we are happy to ignore the client compiler then we can simply copy the jvm.cfg file from amd64 and ignore the rest of the changes. OK to push? Ed. --- CUT HERE --- # HG changeset patch # User Edward Nevill edward.nevill@linaro.org # Date 1384170206 0 # Mon Nov 11 11:43:26 2013 +0000 # Node ID 2940c1ead99bd7635c767f4d585b67fcf7544076 # Parent 445cf19d4a9b534af22783c22cde8bb8274eecf2 Fixes to work around "missing 'client' JVM" error messages