Closed sxa closed 6 years ago
Its caused by the jvm.cfg file, which needs to contain
-j9vm KNOWN
-server IGNORE
The one in jdk/src/solaris/bin/s390x
looks correct, but that isn't the one that's in the final distribution
I think this is because default (non-OpenJ9) build on s390x
is zero
not server
, which means JVMCFG_ARCH
in CopyFiles.gmk
ends up as zero
instead of s390x
so it doesn't copy the correct file. @pshipton I'm not sure where the fix for this needs to be. I'm happy to do it, but want it in the "correct" repo wherever that is.
We could just modify the zero/jvm.cfg
in this repository to include the j9vm
options for now, since that's what we'll always be building but that doesn't feel ideal. The other option would be to add extra logic into jdk/make/CopyFiles.gmk
(Or can it be done using a change in jdk/make/CopyFiles.gmk
?)
Strangely when we do builds they don't have the same issue, it picks up a jvm.cfg with -j9vm KNOWN
and the build runs. We don't seem to be doing any special i.e. bash ./configure --with-boot-jdk=/sdk/openjdk7/linux_390-64_cmprssptrs --enable-cuda --with-freemarker-jar=/tools/freemarker-2.3.8/lib/freemarker.jar && make images
.
We don't want to have modifications to OpenJDK so modifying jdk/make/CopyFiles.gmk
is not ideal, unless the modifications can be contributed to OpenJDK.
Agreed - so my PR does what we've done for the other platforms -modify the jvm.cfg that is copied so that it copies the "correct" one that the build system is trying to pick up. Of course it might be sensible to delete the s390x
on to avoid confusion, but if it works in some environments that may not be the sensible solution.
Is it definitely working for you on openjdk8 (as opposed to openjdk9?)
Is it definitely working for you on openjdk8 (as opposed to openjdk9?)
Yes.
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-openj9_2018_01_10_03_06-b00)
Eclipse OpenJ9 VM (build 2.9, JRE 1.8.0 Linux s390x-64 Compressed References 20180110_375557 (JIT enabled, AOT enabled)
OpenJ9 - f1ccd6b
OMR - 7a770d6
OpenJDK - 00e69f9 based on Java8_SR5_FP7_20171215_1234_B373586)
Note OpenJDK - 00e69f9 based on Java8_SR5_FP7_20171215_1234_B373586
is a bug, see #22
JVMCFG_ARCH in CopyFiles.gmk ends up as zero instead of s390x
Is there a way to control the default such that our existing changes to the closed/
directory can ensure the OpenJ9 build uses s390x
?
I'm not sure there's an easy way without modifying the common files in the AdoptOpenJDK repositories, but if you know of one (I'm not an expert in the openjdk build system) that would likely be preferable. If JVM_VARIANTS can be overridden to have SERVER in there then that would presumably work (although I can't comment on side effects of that approach ...)
OK so makejdk-any-platform.sh
in the openjdk-build
repo is what sets JVM_VARIANT
to zero
on s390x
.
OK I believe the PR I've just submitted to openjdk-build will resolve this in a more satisfactory way assuming it doesn't have any side effects. Assuming that fix is ok we won't need this PR
Merged and I've kicked off a new bulid so hopefully we'll have a good nightly build available in the next couple of hours
Fixed in https://github.com/AdoptOpenJDK/openjdk8-openj9-nightly/releases/download/jdk8u152-b16-20181001/OpenJDK8-OPENJ9_s390x_Linux_20181001.tar.gz and later builds. Closing
I presume this is somewhere around the
redirector.c
code withinopenj9
if you download the s390x AO8/J9 builds from www.AdoptOpenJDK.net and try to run it you get this error:
Creating a symbolic link from
jre/lib/s390x/server
tojre/lib/s390x/j9vm
allows the JVM to start up, so somewhere along the lines in the build it's still looking forlibjvm.so
in HotSpot's location.