Support for allocation of executable memory

[Felix Cravic]

If it needs to be implemented through JNI, you may be right.

However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code.

Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms.
​You will be able to declare the native methods in Java, but the native library will need to be compiled for multiple platforms (and architecture)
I don't understand why you should emphasize this. Does this bring any additional problems?
​JNI comes with overhead. Correct me if I am wrong, but I believe JIT compilers to work using an important number of stubs to allow de-optimization which would not work well with the said overhead (the alternative would be to move the work into the native code, but it doesn't really serve the original goal of being java-only)
This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related.
So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only".
Cannot disagree here. Though Java would currently not be suited for a project benefiting from such feature, which is a shame considering how little API change it requires (feel free to correct me). The closest alternative we have today is dynamic class loading, which is really good for most use-case but not all.
________________________________
De : Glavo <zjx001202 at gmail.com>
Envoyé : dimanche 21 novembre 2021 20:04
À : Felix Cravic <themode at outlook.fr>
Cc : panama-dev at openjdk.java.net <panama-dev at openjdk.java.net>
Objet : Re: Support for allocation of executable memory

Sorry, in the last sentence of that email, I wanted to say "just" instead of "only".

I am using Google translate to write email. Please forgive me for my problems in grammar and words.

Glavo <zjx001202 at gmail.com<mailto:zjx001202 at gmail.com>> 于2021年11月22日周一 上午3:00写道：
which would involve maintaining a native dependency and building it for every potential platform

If it needs to be implemented through JNI, you may be right.

However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code.

Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms.

 not to mention the fact that every execution will have to pass through JNI/Linker API

I don't understand why you should emphasize this. Does this bring any additional problems?

 I however disagree with the "just"
This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related.
So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only".

Felix Cravic <themode at outlook.fr<mailto:themode at outlook.fr>> 于2021年11月22日周一 上午2:41写道：
I agree that there are reasons why it could not have its place in Panama, like OS limitations complicating the API design & it being another pretty unsafe feature.
I however disagree with the "just", which would involve maintaining a native dependency and building it for every potential platform, not to mention the fact that every execution will have to pass through JNI/Linker API. By that point I doubt that Java would be the right tool for the job, or is it perhaps what you meant?
________________________________
De : Glavo <zjx001202 at gmail.com<mailto:zjx001202 at gmail.com>>
Envoyé : dimanche 21 novembre 2021 19:19
À : Felix Cravic <themode at outlook.fr<mailto:themode at outlook.fr>>
Cc : panama-dev at openjdk.java.net<mailto:panama-dev at openjdk.java.net> <panama-dev at openjdk.java.net<mailto:panama-dev at openjdk.java.net>>
Objet : Re: Support for allocation of executable memory

I don't think Panama should provide special support for it.

To do this, you just need to create the binding of the relevant system API (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) with the foreign linker API and call it.

Felix Cravic <themode at outlook.fr<mailto:themode at outlook.fr>> 于2021年11月22日周一 上午1:01写道：
Hello, I was wondering if there has ever been any discussion about supporting allocation of executable memory (and then its execution). The use cases I have in mind are emulation, very hot paths requiring specialized assembly (which could still fallback to jvm bytecode if unavailable), and a potential option to keep the whole application written in a JVM language.

I doubt that such addition would drastically change the API, perhaps some concern about OS specific restrictions (e.g. write-xor-execute memory protection), and platform not supporting JIT compilation at all (IOS, potentially problematic for Graal & project Leyden)

Discussion would be appreciated!