Support for allocation of executable memory

[Glavo]

You're talking about the way JNI works, not the way Panama Foreign Linker
API works. All the problems you mentioned do not apply to Panama.
The Foreign Linker API does not require you to write any native code, let
alone compile native code. You only need to write pure Java code to
implement it.

Reducing the cost of native calls is also one of Panama's goals. I believe
that the cost of calling native wrappers implemented through the Foreign
Linker API is low enough in common Java running environments.

Forgive me for not being familiar with these system APIs, so I can't
provide you with an example implementation of this function here.
I just copy an example given by the official here. I believe it can make
you understand how the Foreign Linker API works:

// 1. Find foreign function on the C library path
MethodHandle radixSort = CLinker.getInstance().downcallHandle(
                             CLinker.systemLookup().lookup("radixsort"),
...);
// 2. Allocate on-heap memory to store four strings
String[] javaStrings   = { "mouse", "cat", "dog", "car" };
// 3. Allocate off-heap memory to store four pointers
MemorySegment offHeap  = MemorySegment.allocateNative(
                             MemoryLayout.ofSequence(javaStrings.length,
                                                     CLinker.C_POINTER),
...);
// 4. Copy the strings from on-heap to off-heap
for (int i = 0; i < javaStrings.length; i++) {
    // Allocate a string off-heap, then store a pointer to it
    MemorySegment cString = CLinker.toCString(javaStrings[i],
newImplicitScope());
    MemoryAccess.setAddressAtIndex(offHeap, i, cString.address());
}
// 5. Sort the off-heap data by calling the foreign function
radixSort.invoke(offHeap.address(), javaStrings.length, MemoryAddress.NULL,
'\0');
// 6. Copy the (reordered) strings from off-heap to on-heap
for (int i = 0; i < javaStrings.length; i++) {
    MemoryAddress cStringPtr = MemoryAccess.getAddressAtIndex(offHeap, i);
    javaStrings[i] = CLinker.toJavaStringRestricted(cStringPtr);
}
assert Arrays.equals(javaStrings, new String[] {"car", "cat", "dog",
"mouse"});  // true


It is recommended that you read JEP 419 in its entirety first to understand
Panama, or take a look at the description of Panama FFI in this document:

https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md






Felix Cravic <themode at outlook.fr> 于2021年11月22日周一 上午3:21写道：

> 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> 于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> 于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>
> *Envoyé :* dimanche 21 novembre 2021 19:19
> *À :* 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
>
> 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> 于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!
>
>