Support for allocation of executable memory

[Maurizio Cimadamore]

Hi Felix,
as Glavo mentions, changing the memory protection of a memory segment 
shouldn't be too hard using ad-hoc method handle calls. These system 
calls should be available in the default linker lookup, so you should 
not need any extra dependencies (unlike with JNI where you would still 
require a custom shared lib).

This question reminds me of other similar questions around adding more 
support for OS-specific flags around mapped memory segments. I believe 
both are cases where the linker API can be used to use OS-specific 
functionalities.

Also, for some mysterious reasons I can't see some parts of the 
discussion - e.g. I see Glavo answering questions re. performance, but I 
do not see said questions. The very high-level summary performance-wise 
is that, for downcalls (Java->Native) performance should be similar to 
JNI, whereas for upcalls (Native->Java), Panama should be a bit faster 
(2x to 3x, depending on the benchmark). That said, even in downcall 
contexts, the comparison wildly depends on what you are doing. For 
instance, the fact that Panama allows you to specify a custom segment 
allocator for pretty much every operation which generates native memory, 
if used wisely, can lead to further speedup. One example is string 
conversion: in JNI string conversion is hardwired to use malloc to 
allocate the native string. In Panama you can pick whatever allocation 
scheme you want. Since Java->Native string conversion is mostly 
allocation bound, you can get quite a big speedup just by using a more 
performant allocator (e.g. an arena).

At a later point we might investigate other optimization strategies; 
such as eliminating Java/native state transitions for back to back 
calls, or ability to pin regions of heap memory (so that it can be 
passed to native code directly). But those are trickier to get right 
(and can negatively affect performance of the GC subsystem), so we will 
proceed with care.

Maurizio

On 21/11/2021 07:33, Felix Cravic wrote:
> 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!