Closed MikaelUrankar closed 5 years ago
@MikaelUrankar I would recommend a few things for confirming the stability of port.
1) Configure the build with --with-debug-level=fastdebug
and --with-jtreg=<path to jtreg dir>
to get debug info + asserts.
2) Build with gmake LOG=debug all
to get detailed build log and tests built.
3) Test with gmake run-test-only TEST=":tier1 :tier2"
since all aarch64 is mostly inconsistent Tier2- environment we should do an agreement on which hardware/OS-Version/compiler work should be done preferred , e.g. Cortex-SBCs(I have RPI3(FreeBSD)/Rock64(OpenBSD/NetBSD), AWS Graviton or ThunderX...... or?
why is this bold? .. don't know
The hs_pid_xxx.log file can have useful information, but to see what's causing the core dump is going to need a fastdebug build in my experience on OpenBSD.
I haven't experimented with OpenBSD aarch64 yet. For the time being I think using the best supported hardware for FreeBSD make sense.
The hs_pid_xxx.log file can have useful information, but to see what's causing the core dump is going to need a fastdebug build in my experience on OpenBSD.
I haven't experimented with OpenBSD aarch64 yet. For the time being I think using the best support hardware for FreeBSD make sense.
for FreeBSD that is (only) ThunderX, available here : https://www.packet.com/cloud/servers/c1-large-arm/ 0,50$/hr. , is it worth ? Mikael, what clang/gcc/fbsd-versions did you compile on ?
ah, forgot to say : the FreeBSD- bootstrap is not ELF-compatible with aarch64 OpenBSD, would be a hard task on that slow SBC-boards to NFS-bootstrap..
You need at least 12-stable (there are some rtld bugs on 11.x and 12.0) But I build in a 11.2 jail (with /libexec/ld-elf.so.1 from 13-current).
cc -v
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
It builds fine on -current with clang8 on my tx1. I'll try with my rpi3 later today.
ah, forgot to say : the FreeBSD- bootstrap is not ELF-compatible with aarch64 OpenBSD, would be a hard task on that slow SBC-boards to NFS-bootstrap..
I managed to bootstrap lang/ghc on my rpi3, it was tedious but not impossible.
You need at least 12-stable (there are some rtld bugs on 11.x and 12.0)
well, fortunately there's 12-stable on AWS where we all could work on, if needed : e.g. : ami-0433313756a4e0354 , Region : (EU) Ireland ... didn't search for OpenBSD/NetBSD on all regions but I guess: not available there ( not all Regions have aarch64)
@klaus4: which bootstrap did you use? Can you try with this one? http://mikael.urankar.free.fr/FreeBSD/aarch64/bootstrap-openjdk11.tar.xz
that's the bootstrap I used, afai-remember, the other bootstrap-file on your website was called 11 but was openjdk12(which can not work as bootstrap for 11), thank you
@klaus4: the crash is a bug in adlc (it happens on openjdk11 and openjdk12): https://gist.github.com/MikaelUrankar/6e86f2ecb80e09f1e6c872820cca59db It doesn't crash if the libc is built with MALLOC_PRODUCTION=yes (which is the default on -release branch) I gave a quick look at adlc in jdk11, return code after allocation (malloc) are never checked (it got fixed in openjdk12)... I stopped looking at it after that.
@klaus4: the crash is a bug in adlc (it happens on openjdk11 and openjdk12): https://gist.github.com/MikaelUrankar/6e86f2ecb80e09f1e6c872820cca59db It doesn't crash if the libc is built with MALLOC_PRODUCTION=yes (which is the default on -release branch) I gave a quick look at adlc in jdk11, return code after allocation (malloc) are never checked (it got fixed in openjdk12)... I stopped looking at it after that.
Looking at the related code, I would venture a guess that things have gone wrong in src/hotspot/share/adlc/adlparse.cpp. If it's another clang optimization type issue, you may want to try a slowdebug build which builds at -O0 to see if it reproduces there too. Stepping through the code with gdb and watching for where ADL_Parse->_ptr goes wrong may also help isolate the issue.
well, small "Water level" from here: dmesg.txt configure.log.txt build.log.txt
both my own feature-branch with patch from upstream and branch from git clone -b freebsd-aarch64 https://github.com/MikaelUrankar/openjdk-jdk11u.git do the same.
since c1_LIRAssembler_aarch64.cpp is one of the files from the upstream patch I don't know whether to continue with "wild hacking" those files or not :-)
[gmake ... -Wno-unnamed-type-template-args .... ] has no effect , to be honest in clang I never succeeded surpressing those warnings/errors, perhaps there is a trick I don't know..
--- edit: ---
dtrace was disabled because also ends up with clang-errors( which isn't surprising on aarch)
.. http://hg.openjdk.java.net/jdk/jdk11/raw-file/tip/doc/building.html#building-on-armaarch64 http://hg.openjdk.java.net/jdk/jdk11/raw-file/tip/doc/building.html#building-for-armaarch64 ?
@klaus4 configure with --disable-warnings-as-errors
for the time being. I'd also suggest building with gmake LOG=debug all
to get detailed build logs that include arguments passed to clang.
@klaus4 configure with
--disable-warnings-as-errors
for the time being. I'd also suggest building withgmake LOG=debug all
to get detailed build logs that include arguments passed to clang.
--disable-warnings-as-errors -> ouch ... unbelievable that i forgot this flag :-), thanks
@battleblow all patches you comment were imported from the upstream by Mikael : http://hg.openjdk.java.net/jdk/jdk/rev/e53ec3b362f4 (recommended by Kurt above)
Anyway, I'm hanging here right now :
/root/openjdk-jdk11u/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp:245:1: error: no member named 'ExitedWithCode' in namespace 'testing'
TEST_OTHER_VM(CollectorPolicy, young_cmd) {
^~~~~~~~~
/root/openjdk-jdk11u/test/hotspot/gtest/unittest.hpp:67:28: note: expanded from macro 'TEST_OTHER_VM'
::testing::ExitedWithCode(0), \
/root/openjdk-jdk11u/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp:267:1: error: no member named 'ExitedWithCode' in namespace 'testing'
TEST_OTHER_VM(CollectorPolicy, old_cmd) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/root/openjdk-jdk11u/test/hotspot/gtest/unittest.hpp:67:28: note: expanded from macro 'TEST_OTHER_VM'
::testing::ExitedWithCode(0), \
~~~~~~~~~~~^
2 errors generated.
Regards
Try with --disable-hotspot-gtest, it's in the FreeBSD ports Makefile
well done, Mikael ! after --disable-hotspot-gtest and installing the alsa-libs the release-build succeeded. from my view PR can be merged
if you want further tests from me or make the AWS-AMI public, let me know
so the next thing for aarch could be a look @ dtrace-implementation
I merged a fix for the adlc segfault and gtest build failure into bsd-port. @MikaelUrankar if you rebase your freebsd-aarch64 branch on bsd-port with these fixes it should correct those issues.
I setup a FreeBSD 13-current aarch64 node at aws and am running a gmake run-test-only TEST=":tier1 :tier2"
test now. So far so good with the exception of the issue raised in #51.
@MikaelUrankar oh I forgot to mention, building on FreeBSD 13-current needed a patch to src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp
since some #defines changed. I needed this to build there:
diff --git a/src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp b/src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp
index 847cbf5e98..eb1c0d5d58 100644
--- a/src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp
+++ b/src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp
@@ -1,6 +1,23 @@
#ifndef CPU_AARCH64_VM_BSD_AARCH64_HPP
#define CPU_AARCH64_VM_BSD_AARCH64_HPP
+// for FreeBSD-13
+#ifndef ID_AA64PFR0_ADV_SIMD_SHIFT
+#define ID_AA64PFR0_ADV_SIMD_SHIFT 20
+#endif
+
+#ifndef ID_AA64PFR0_ADV_SIMD_MASK
+#define ID_AA64PFR0_ADV_SIMD_MASK (0xf << ID_AA64PFR0_ADV_SIMD_SHIFT)
+#endif
+
+#ifndef ID_AA64PFR0_ADV_SIMD
+#define ID_AA64PFR0_ADV_SIMD(x) ((x) & ID_AA64PFR0_ADV_SIMD_MASK)
+#endif
+
+#ifndef ID_AA64PFR0_ADV_SIMD_IMPL
+#define ID_AA64PFR0_ADV_SIMD_IMPL (0x0 << ID_AA64PFR0_ADV_SIMD_SHIFT)
+#endif
+
Although perhaps you may want to use the newer names in -current and put in backward compat defines for 11/12 instead of what I did above.
Separately, I still feel the new header src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp
doesn't fit well with how Oracle has structured things. After reviewing it more I think the contents of the new header and the FreeBSD specific code in src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
should be moved into a new VMVersion method in src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp
similar to the way that VM_Version::get_os_cpu_info()
is done in src/hotspot/os_cpu/linux_arm/vm_version_linux_arm_32.cpp
.
I'll try to find time to code up what I'm suggesting and make a pull request to your fork. I'm not sure if I will be able to pull it off before I go on vacation though.
Edit: fixed get_os_cpu_into() file name.
I merged a fix for the adlc segfault and gtest build failure into bsd-port. @MikaelUrankar if you rebase your freebsd-aarch64 branch on bsd-port with these fixes it should correct those issues.
Many thanks. Out of curiosity, how did you debugged the adlc issue?
I setup a FreeBSD 13-current aarch64 node at aws and am running a
gmake run-test-only TEST=":tier1 :tier2"
test now. So far so good with the exception of the issue raised in #51.
I was thinking of something like this (and merge bsd_aarch64.hpp into vm_version_aarch64.hpp: https://gist.github.com/MikaelUrankar/13f018a2705b6dea7240c8f2ee69f3f5)
@MikaelUrankar oh I forgot to mention, building on FreeBSD 13-current needed a patch to
src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp
since some #defines changed. I needed this to build there: Although perhaps you may want to use the newer names in -current and put in backward compat defines for 11/12 instead of what I did above.
I'm aware of the recent change. Anyway, I'm targetting 12.1-RELEASE for this java work and the new define will be MFC'ed by then.
Many thanks. Out of curiosity, how did you debugged the adlc issue?
After confirming the issue existed with slowdebug (ruling out clang opto issues), I built a fastdebug build, but found that adlc was stripped anyway. So I deleted the adlc binary and added this to get a debugable adlc binary:
diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk b/make/hotspot/gensrc/GensrcAdlc.gmk
index 67124ff845..fa84422a0e 100644
--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -75,7 +75,8 @@ ifeq ($(call check-jvm-feature, compiler2), true)
LIBS := $(ADLC_LIBS), \
OBJECT_DIR := $(JVM_VARIANT_OUTPUTDIR)/tools/adlc/objs, \
OUTPUT_DIR := $(JVM_VARIANT_OUTPUTDIR)/tools/adlc, \
- DEBUG_SYMBOLS := false, \
+ DEBUG_SYMBOLS := true, \
+ STRIP_SYMBOLS := false, \
DISABLED_WARNINGS_clang := tautological-compare, \
DISABLED_WARNINGS_solstudio := notemsource, \
))
After that it was a pretty typical debug session. I worked my way backwards until I realized the parsing was fine and that ADLParser::cisc_spilling_operand_name_parse() was never called so it lead me back to the constructor for FrameForm.
I was thinking of something like this (and merge bsd_aarch64.hpp into vm_version_aarch64.hpp: https://gist.github.com/MikaelUrankar/13f018a2705b6dea7240c8f2ee69f3f5)
I think I led you astray with my initial recommendation to use os_bsd_aarch64.cpp. There already is a os_cpu/bsd_aarch64/ file for vm_version. Here's a diff along the lines of what I was thinking. It builds but I ran out of disk space so its untested and needs to be cleaned up a bit:
I'm heading out for a vacation soon so I don't want to hold up this pull request. With something similar to the diff above I'm happy with the pull request. Thank you for working on this.
I ran out of disk space while running gmake run-test-only TEST=":tier1 :tier2"
(I had a second build of the jdk running that used up the space) but here's the output up until it failed:
I haven't had time to review this, but I thought it would be helpful to see which tests have crashes for further investigation.
I ran out of disk space ...
:-) I experienced the same , on EC2 you can expand the volume to e.g. 20GB,
then in FBSD expand the / partition via gpart,
since growfs doesn't work on UFS in the AMI, I typed
service growfs onestart
and that worked ..
Okay, looking at moving this forward, can I ask that you rebase the pull request so that there are only two commits in it.
Commit 1: The import of http://hg.openjdk.java.net/jdk/jdk/rev/e53ec3b362f4 Commit 2: BSD aarch64 support
The reason I'm asking this is that I'll need to merge the changes forward into newer versions. This way I'll only need to merge two commits rather nine (which makes it easier to track) while preserving the split between new BSD code and upstream changes, since the upstream changes only need to be merged into 12 and 13 (not 14).
If it's easier, please feel free to do the rebasing on a separate branch and send a new pull request from there.
Done.
If you want to see the log: http://mikael.urankar.free.fr/FreeBSD/aarch64/openjdk11-aarch64-jdk.log