Prevent class initialization failure when JVM has no support for native code at all (wrong platform)#15844
Conversation
…ing. A previous refactoring broke this
|
10.x has the same problem, I will backport. |
uschindler
changed the title
|
I tested this again with several hardcoded changes, an integration test is still missing:
To allow better testing I added the new Java 24 command line flag to enforce "deny" when native access is done. As we see, this breaks FAISS, so I will look into this. |
|
FAISS was fixed by passing correct command line |
|
In this PR I also added an extra check for 64bit JVM, because 32 bit support of madvise won't work on 32 bit (wrong posix_madvise signature). This is not really an issue because MMapDir is not used by default and many platform with 32 bits are no longer supported in Java 25, but we should still check this. |
|
It is hard to add an integration test for disabled native access. I leave this open for a separate PR. |
|
I am not sure why the Github runner fails. Looks like a bug on Github at moment. Will try to run workflow later. |
|
Here is the error:
|
|
See my message on the dev list. We need to update our actions. I contacted asfinfra on Slack and theres heavy committing at moment. |
…o dev/fix-PosixNativeAccess-clinit
|
Thanks @rmuir for updating main branch, looks like checks run again. |
|
Hi, In addition, I changed |
uschindler
added
the
skip-changelog
|
About the page size I opened: https://bugs.openjdk.org/browse/JDK-8380572 |
| return (OS_ARCH != null && OS_ARCH.contains("64")); | ||
| } | ||
| } | ||
| public static final boolean JRE_IS_64BIT = (ValueLayout.ADDRESS.byteSize() == Long.BYTES); |
…ve code at all (wrong platform) (#15844) * Fix loading of PosixNativeAccess class when native access is not working. A previous refactoring broke this * Only use madvise on 64 bit platforms * Add more safety when linker throws illegal argument Exception; improve logging
3 participants
See #15843 for more details. Actually the problem is that looking up the default linker may throw UnuspportedEx when the platform does not allow native code at all.
This was caused by the refactoring where the symbol and linker lookup was moved outside the try-catch: 3003731
This could cause class loading issue es described in #15834 because it may break initializing of NativeAccess class.
The PR also catches the general problem case if the underlying linker does not support the
FunctionDescriptor.It also disables madvise on 32 bits: We could support it, but then we would need to ask the linker for the java type behind
size_t(this works), but depending on the type we would need to map the returnedMethodHandleby explicit casting to adapt to long (our Java call signature). This is not worth it, because MMapDir is not used on 32 bit platforms by defaulr.