[GR-49729] [Espresso] Support running without native access.

[gilles-duboscq]

Feature request

Is your feature request related to a problem? Please describe.
Espresso requires native access to run the JDK's native libraries. Native access is also requires due to the implementation of Unsafe.
As a result, to run espresso in a polyglot context it requires all access.

Describe the solution you'd like.
Some of the JDK's native methods could be implemented without having to call native code.
Unsafe can be virtualized in a way that it doesn't require native access.

Describe who do you think will benefit the most.
Users who want to run espresso in a polyglot context without having to enable all access or native access.

Describe alternatives you've considered.

• The security manager can be used to impose some restrictions in the espresso context but it is being removed.
• Sulong can be used to run the JDK's native code but that still requires native access in order to call into system libraries. It is also not always straightforward to produce bitcode for the JDK for all platforms.

Additional context.
The I/O part of the JDK would be taken care of by #4625.
The following JDK 21 modules contain native code and are relevant for espresso:

• java.base
• java.desktop
• java.management
• java.rmi
• java.security.jgss (kerberos)
• jdk.jdi
• jdk.management

java.desktop is too vast to realistically be implemented without calling into the native code.

The following JDK 21 modules contain native code but are unlikely to be used in a no-native espresso context:

• java.smartcardio (ISO/IEC 7816 smart cards)
• jdk.crypto.cryptoki (PKCS#11 tokens)

The following JDK 21 modules contain native code but are not relevant for espresso:

• jdk.hotspot.agent
• jdk.jdwp.agent
• jdk.jpackage

Express whether you'd like to help contributing this feature
If you'd like to contribute, please read the contribution guide.

[kumargu]

thanks @gilles-duboscq for putting this up!

Unsafe can be virtualized in a way that it doesn't require native access.

I am noob in this area, but this seems a lot of work.

Would you be able to give a high level estimate of the quantity of work? (sorry for asking the hard part of it so early, but i am evaluating if we (Opensearch) would be able to use it any time in Q1 2025).

[kumargu]

tagging Opensearch's meta issue for referencing opensearch-project/OpenSearch#1687

[gilles-duboscq]

Regarding unsafe: I don't think that's a lot of work, all unsafe field accesses are already "virtualized": we find the field that is accessed from the offset and then perform the access.
What requires work are the raw memory accesses (e.g., method that take a long address as argument). For those we have to maintain a virtual address space that we can back with host byte buffers.

Regarding the timeline. We had explored the subject a few months ago. We might be able to merge some of the building blocks based on that.
However Q12025 seems tight since the next release is planned for mid-March with a feature freeze on the 23rd of January.

[kumargu]

thanks for the callout on the dates. Agreed Jan would be really a stretch; but the fact that we could get this in production is really exciting news and opens a new door for security manager alternative. I am going to discuss this option more verbally internally with our team.

At the same time, we will be happy to help with contributions on the issue.