Thread safety check of MemorySegment

[Maurizio Cimadamore]

On 21/07/2020 21:01, Uwe Schindler wrote:
> Hi,
>
> Why does it not work for mapped segments, is this a bug? I was about 
> to test this for Lucene...

MemorySegment.ofNativeRestricted is a factory which creates a segment 
based on an existing address. It's meant to be used for e.g. managing 
memory manually - e.g. if you want to create a segment out of an address 
you retrieve from native code. In other words, this is the Panama 
equivalent of the JNI function ... The fact that you can use this to 
create an unconfined segment is mostly accidental. While in some cases 
that can be used as a workaround, it doesn't really make sense, from an 
API perspective, to extend that workaround to mapped segments. The 
*right* solution from an API perspective is to find a way to disable 
confinement in a way that works, which is what we're exploring.

In the past I've already shared some snippets of how the restricted 
factory could be used, together with the foreign function support to 
create custom mapped segments that are not confined:

https://gist.github.com/mcimadamore/128ee904157bb6c729a10596e69edffd

Implementing custom memory segments is the main reason as to why the 
restricted segment factory has been added, so that developers could e.g. 
implement custom native allocators and expose the allocated memory as 
segments.

> In MemorySegment::ofNativeRestricted, cleanup is required as a 
> parameter. Is there any way I can get this Runnable?
We considered this a bit - at some point we wanted to make the callback 
parameter an AutoCloseable, so that you could also pass a segment as a 
callback (since segments are autocloseable) - but then decided against it.

While something like this can be done, I think that it is more important 
to invest on finding ways to construct unconfined segments w/o the need 
of resorting to escape hatches like ofNativeRestricted, rather than 
enhancing said hatches for things they were not designed to do, sorry :-)


>
> Anyways, in which JDK will the current code be part of? 15 or 16?

This will be in Java 15.

Maurizio

>
> Uwe
>
> Am July 21, 2020 5:49:46 PM UTC schrieb Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com>:
>
>     On 21/07/2020 15:03, Maurizio Cimadamore wrote:
>
>         If you have a MemoryAddress and want to create an unsafe
>         segment from it which is not confined, you can use the
>         MemorySegment::ofNativeRestricted factory, at least as a
>         temporary workaround. Doesn't work (as pointed out earlier in
>         this mailing list) if you are after mapped segments, but for
>         plain native segments should work fine. E.g. MemorySegment
>         segment = MemorySegment.allocateNative(100); MemorySegment
>         unconfined =
>         MemorySegment.ofNativeRestricted(segment.baseAddress(), 100,
>         null, null, null); // from now on, just use unconfined
>         Maurizio On 21/07/2020 14:54, 虾米Mickey wrote:
>
>             Hi, I am using foreign to develop indie games. A library
>             called bgfx is used. There is a function,
>             https://bkaradzic.github.io/bgfx/bgfx.html#_CPPv4N4bgfx7makeRefEPKv8uint32_t9ReleaseFnPv
>             There is a clear requirement for the incoming memory
>             release callback: ReleaseFn function must be able to be
>             called from any thread. Due to MemorySegmentImpl::close ->
>             MemorySegmentImpl::checkValidState, this will result in
>             IllegalStateException("Attempt to access segment outside
>             owning thread") Currently I release the memory through
>             segment.scope().close(), of course this is not a direct
>             call. Should there be a more direct way to release
>             operations under unsafe conditions? Thanks and regards,
>             NekoCaffeine 
>