[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9466:
------------------------------------
Description:
ByteBufferInputStream has a method determineUnaligned that will always fail on
java 16 and later. This is because it calls Method.setAccessible which is not
allowed under normal conditions starting with java 16 (see:
[https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16|https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/[]).
The method is called when the class is loaded so it will cause the class load
to fail. It tries to handle exceptions on return false but the exception java
16 throws is a RuntimeException and that is not caught. The exception it will
fail with is java.lang.reflect.InaccessibleObjectException.
A workaround for this bug is to start the jvm with --illegal-access=permit
This causes ByteBufferInputStream to do a bunch of its work a byte at a time
instead of using the optimal multi-byte methods like readShort, readInt, and
readLong.
It would be simple to change determineUnaligned to catch RuntimeException from
setAccessible and then to read the "os.arch" system property and if it is any
of the following to return true:
{code:java}
arch.equals("i386") || arch.equals("x86")
|| arch.equals("amd64") || arch.equals("x86_64")
|| arch.equals("ppc64") || arch.equals("ppc64le")
{code}
This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
UnsafeConstants and its value is injected by the JVM so it is unclear if the
list has grown.
was:
ByteBufferInputStream has a method determineUnaligned that will always return
false on java 16 and later. This is because it calls Method.setAccessible which
is not allowed under normal conditions starting with java 16 (see:
https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/[).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
This causes ByteBufferInputStream to do a bunch of its work a byte at a time
instead of using the optimal multi-byte methods like readShort, readInt, and
readLong.
It would be simple to change determineUnaligned in its exception catch block to
read the "os.arch" system property and if it is any of the following to return
true:
{code:java}
arch.equals("i386") || arch.equals("x86")
|| arch.equals("amd64") || arch.equals("x86_64")
|| arch.equals("ppc64") || arch.equals("ppc64le")
{code}
This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
UnsafeConstants and its value is injected by the JVM so it is unclear if the
list has grown.
> ByteBufferInputStream slower on Java 16 and later
> -------------------------------------------------
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Improvement
> Components: core
> Reporter: Darrel Schneider
> Priority: Major
> Labels: Java16
>
> ByteBufferInputStream has a method determineUnaligned that will always fail
> on java 16 and later. This is because it calls Method.setAccessible which is
> not allowed under normal conditions starting with java 16 (see:
> [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16|https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/[]).
> The method is called when the class is loaded so it will cause the class load
> to fail. It tries to handle exceptions on return false but the exception java
> 16 throws is a RuntimeException and that is not caught. The exception it will
> fail with is java.lang.reflect.InaccessibleObjectException.
> A workaround for this bug is to start the jvm with --illegal-access=permit
> This causes ByteBufferInputStream to do a bunch of its work a byte at a time
> instead of using the optimal multi-byte methods like readShort, readInt, and
> readLong.
> It would be simple to change determineUnaligned to catch RuntimeException
> from setAccessible and then to read the "os.arch" system property and if it
> is any of the following to return true:
> {code:java}
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> {code}
> This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
> UnsafeConstants and its value is injected by the JVM so it is unclear if the
> list has grown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)