Update and unify JNA #322
Merged
Update and unify JNA #322
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The newer JNA should provide support for more platforms/architectures and the slf4j-simple binding silences SLF4J warnings on startup.
Even though these two benchmarks might not get to actually using JNA (in scala-dotty, it's apparently needed by the jline-terminal), but the newer JNA supports more architectures, and this unifies JNA version with the one forced onto db-shootout.
JNA 5.10.0 includes an architecture mapping fix for SAP JVM and should make it possible to run the database benchmark on S390x platform under SAP JVM.
|
JNA 5.10.0 with the fix to architecture mapping on SAP JVM (java-native-access/jna@91eb8c2) was just released. I'm bumping the JNA version in this PR, which should address #153. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was primarily triggered by the issues with
db-shootouton less common CPU/platform combinations (see #153 and #296) and at least part of the cause is that JNA version (4.2.1) used indb-shootoutsimply does not support those combinations. So this forces JNA indb-shotoutto version 5.9.0 (latest at the moment) which provides support for currently live combinations and loses a few outdated ones, specifically:aix-ppc64,darwin-aarch64,darwin-x86-64,linux-armel,linux-mips64el,linux-ppc(32-bit),linux-riscv64,linux-s390x, andwin32-aarch64darwin(replaced bydarwin-x86-64I think),linux-ppc64(there is stilllinux-ppc64le),linux-sparcv9(there still issunos-sparcv9) andw32ce-armGiven the two issues mentioned, we are mostly interested in getting
darwin-aarch64,linux-ppc64leandlinux-s390xsupport which the newer JNA provides.Also, because the
neo4jandscala-dottybenchmarks pull in JNA as a (transitive) dependency, I forced them to pull the same (latest) version so that we don't have three different JNA versions each supporting a different set of CPU/platform combinations. I don't know if these benchmarks actually get to executing any code that relies on JNA (not sure aboutneo4j, butscala-dottymight pull it in just because some part of Scala wants to usejline-terminalandjline-terminal-jnafor REPL).Anyway, the benchmarks compile and run on my machine (which is expected), but unfortunately I don't have info about the exotic platforms involved in the original issues.
I created a branch and a special build (including binaries) of
db-shootoutthat the original issue posters could use to check if it fixes their problem, but I haven't received any response so far.So the question is, do we want to merge this and move on?