Aarch64 support? about jvm-driver HOT 6 CLOSED

Hello! If you use the default driver these architectures should already be supported because this type of driver is pure Java based and doesn't use the native module. But if you use the other drivers (dynamic, hybrid and native) you also need to compile the native module for the relative architecture. I would like to compile the native module for aarch64 but I need to understand how to do it (GitHub action seems that doesn't have an aarch64 environment): if you are able to compile native code on aarch64 can you explain to me via Skype how to compile it?

from jvm-driver.

I see. I was naively assuming that things like Modules.exportAllToAll() was relying on the native module and "strong encapsulation" not being enforced for JNI, but upon closer inspection I see that method handles and runtime bytecode compilation of e.g. AccessibleSetterInvokerForJDK9.bwc is used to circumvent these restrictions. Maybe my question should rather be how this works. As a potential user I'd like to understand the mechanism that enables circumvention of encapsulation and so better be able to reason about circumstances in which this might not work, whether this is likely to continue working in the future, etc.

from jvm-driver.

As you can see there are 4 types of drivers and the native driver works without tricks and taking full advantage of the JNI function which, as you already know, has no restrictions. The default driver fully uses the java code and the *.bwc files also correspond to the java classes that you can find in the java hook project. Explaining how the strong encapsulation is bypassed is a bit complex and relies not on one mechanism but on a number of mechanisms. Unfortunately I cannot guarantee that the default driver will work forever and for now it works for all java versions up to 19 ea. The native driver, on the other hand, is tied to the JNI interface and as long as this does not undergo revisions this type of driver will continue to work. The purpose of the driver is not to guarantee the functioning of the java code forever, but to give the possibility to those who have found software no longer working since JDK 9 to extend its life a little more. As for the native driver unfortunately at the moment I am not able to compile the native module for other platforms but if you or any other person could do it they would be welcome

from jvm-driver.

Thanks for explaining. I agree with the goals of this project and the fact that it cannot be guaranteed to work forever. I also appreciate that the pure java circumvention is complex. This makes me even more curious as to how the different pieces come together and having this described would be valuable for users to understand failure modes as well as general knowledge spreading, especially if contributions to this project are desired. Even a terse description of just the key tricks would be much appreciated.

I see that the hooks are compiled as if they were part of the jdk packages, but not sure why using e.g. AccessibleSetterInvokerForJDK9 doesn’t fail at runtime. Is that where using Unsafe.defineAnonymousClass to load them helps?

from jvm-driver.

Thanks for explaining. I agree with the goals of this project and the fact that it cannot be guaranteed to work forever. I also appreciate that the pure java circumvention is complex. This makes me even more curious as to how the different pieces come together and having this described would be valuable for users to understand failure modes as well as general knowledge spreading, especially if contributions to this project are desired. Even a terse description of just the key tricks would be much appreciated.

I see that the hooks are compiled as if they were part of the jdk packages, but not sure why using e.g. AccessibleSetterInvokerForJDK9 doesn’t fail at runtime. Is that where using Unsafe.defineAnonymousClass to load them helps?

Ok, I will explain it to you but privately via Skype or Whatsapp: send me your references to the email [email protected]

from jvm-driver.

I added support for aarch64 in the new version but it needs testing. I close the issue and if there are problems at runtime with the loading of the library for the aforementioned architecture, open a new issue

from jvm-driver.