Raspberry Pi failure with OpenJDK

[peardox]

Yes, I know you already know but that was tagged on to the HDF5 stuff so proper bug report time

Is there still a skip tests switch? I wanna do presets hdf5 for you.

This is an ARMHF 32bit on a Raspberry Pi4 with stock OS (a Debian Buster fork)

Of note is this which occurs right at the start - possibly the problem? Full log attached.

debug.jcpp.zip

WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release

[saudet]

Duplicate of #347

[saudet]

That's already fixed in commit https://github.com/bytedeco/javacpp/commit/606ac566a6837bd971318834e88be343e8bd080f. Please make sure to get the latest code.

[peardox]

I got the latest code, in fact that server saw daylight < 12 hours ago and, yes - I can see your fix...

It don't work

Presets is having issues as well on armhf

[saudet]

@peardox Would it possible for you to find out on which line of PointerTest.java it crashes?

[peardox]

The problem appears to lie with the Debian Buster / Pi4 Java (log attached above)

I've been experiencing the same startup issues when trying a Tensorflow build for 32bit (resorted to cross compilation - there's a first time for everything)

When doing a Bazel build from source the same junk happens

The ...

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method

```Stuff only occurs on the stock OS

[saudet]

I see that you're trying to use OpenJDK, but that's not well supported for ARM. Make sure to obtain Oracle JDK and use that instead.

[peardox]

Does the version of JDK matter?

I tend to default to 8 as that's what I'm porting to Arm forced on me - also resulting in old version of everything else, JCPP et al

[peardox]

Just installed Oracle JDK for arm32 on the Pi and JCPP compiles perfectly without bitching or the PointerTest.java crashing horribly + dying

I'll start JCPP-Presets going - takes hours and will defo fail when it hits Systems as it uses glibc 2.28.

I'll try it out on the test Pi4 - arm64 in the AM after 32bit's crashed...

Prob need a wiki bit writing for the Pi - not a lot of info out there on stuff like this for the Pi plus a step-by-step howto install Java from Oracle's tarball is prob required. Actually sod all info about arm in general + when it does exist it's wrong (Tensorflow being a case that springs to mind)

[saudet]

With Amazon pushing for ARM, that might change: https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/downloads-list.html https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/downloads-list.html

/cc @kwatters

[peardox]

They're specifically not addressing JavaFX issues https://github.com/corretto/corretto-8/issues/26

Amazon obviously want this for servers and JFX is a desktop feature so of little interest to them I guess

JCPP is used on desktops and servers so the Java problems persist

[saudet]

JDK 8 is in maintenance mode now. Work for that is happening with JDK 11: https://gluonhq.com/products/javafx/

/cc @johanvos

[vb216]

If you've not seen it, this might be of interest for a solution - https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support

Not had time to play with it, but could be a nice add in to the CI pipeline, perhaps keep the cross compile (might help maintain portability) but could run tests on arm.

Also looks like they support Windows images too.

[vb216]

Had a little play, looks plausible approach: https://travis-ci.org/vb216/javacpp/jobs/609608177/config where that config could just be expanded out with additional jobs, probably use the existing one as the one that actually pushes the artifacts, and use arm64 as test cases?

Since javacpp is so quick to build, seems easy just to build again with the test cases run on arm64, and possibly with other openjdk's if thats desirable.

Javacpp-presets.. not so sure on best way forward. Seems to be a lot of people doing native builds, so could do that too, but having put all the effort into cross compiling would seem unwise to let that drop too.

Any preferences on whats most value to look at?

[saudet]

@vb216 Adding a new job to test JavaCPP on ARM sounds easy enough and would be useful, yes. Please send a pull request :) Travis CI still doesn't support POWER though, and the presets still don't have tests to run anyway, so I wouldn't change things just for ARM there. We could run the tests for JavaCV on ARM easily enough too though. That indirectly tests some of the presets.

[vb216]

OK, shouldn't take too long. Out of interest, is there a significant POWER user base? I remember you added it in a year or so ago, I assume it's commercial users? Might see if there's a way to run a sort of 'test branch' in a Travis build, would be interesting to run native arm builds but without holding up the main pipeline as that's already pretty long

[saudet]

I'm not hearing much from POWER users these days, but since NVIDIA supports POWER more than ARM, I assume it's not negligible...

[saudet]

Also OpenJ9 builds are available for POWER, but not ARM...

[vb216]

OK, small update built in that PR. Looks like its picking up openjdk8 for ARM, though could be tweaked for others I'm sure. Had a crack at using their windows builds but that's a bigger undertaking.

[saudet]

Looks like Anaconda is also available for POWER these days, but not ARM: https://www.anaconda.com/distribution/

[vb216]

Pretty cool development - they've updated the list of supported CPUs further now https://docs.travis-ci.com/user/multi-cpu-architectures/ - looks like powerpc has made the list!

I think its still a bit beta - ARM seems to have gone AWOL in the last 24h. But given how well the rest of their platform works, am sure it'll be stable soon. That'll be pretty comprehensive, all the big OS's, and 4 CPU arch.

arch:

• amd64
• ppc64le
• s390x
• arm64

[saudet]

We also have GitHub Actions these days and that supports build times of up to 6 hours like this: https://github.com/saudet/tensorflow-java/commit/85dbc76cd253bbaf35f7854a358cbba38c289252/checks?check_suite_id=367710593 There are still a few issues with it though, for example: https://github.community/t5/GitHub-Actions/Error-quot-The-paging-file-is-too-small-for-this-operation-to/m-p/41713#M4723

/cc @Neiko2002

[saudet]

Thanks everyone for the help with this! It looks like all bugs have been identified and fixed, but I'll leave this opened as "enhancement" about needing more testing for Raspberry Pi, specifically.