Support for allocation of executable memory

[Paul Sandoz]

Hi,

Replying at the top of the thread.

This reminds me of the early days experimenting with native code snippets and binding them to method handles. We prototyped that for use with vectorization. 

See http://cr.openjdk.java.net/~psandoz/conferences/2015-JavaOne/j1-2015-unsafe-CON7076.pdf

That was in 2015! It's very encouraging to reflect back on that and see the progress with Project Panama.

As shown in the thread it's possible with Panama’s FFM API to do something similar, but the degree of optimization compared to C2 intrinsics will be limited right now. The code snippets prototype was more optimally integrated with C2, more intrinsic-like than native-like. Perhaps over time it may be possible to close the gap for certain kinds of native functionality (i.e. like that internal JNI fast path the name of which escapes me right now), which depends on the properties of that functionality. 

Paul.

> On Nov 20, 2021, at 11:33 PM, Felix Cravic <themode at outlook.fr> 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!