MemorySegment.close(), threads

[Jorn Vernee]

I've filed: https://bugs.openjdk.java.net/browse/JDK-8237351

Cheers,
Jorn

On 16/01/2020 12:36, Maurizio Cimadamore wrote:
>
>>>
>> Oh ok, does it?  The documentation says it doesn't and I recall 
>> seeing some odd results when i didn't initialise all fields.  At 
>> least that's the way i read it from the source:
>
> Ouch - you caught a bug in the API javadoc. We now do zero memory by 
> default - in the future there will be API ways to decide whether 
> zeroing should be applied or not. I will fix this javadoc issue upstream.
>
> Related to your issue with freeing upcall stubs, Jorn and I discussed 
> this yesterday and came up with an idea which, I think, should address 
> your concerns. Basically, the idea is:
>
> * upcall stub address are based on the Nothing segment; as such they 
> can be passed opaquely, cannot be dereferenced, cannot be closed
> * SystemABI will provide an extra method to explicitly *free* an 
> upcall stub (rather than relying on the closure of the segment 
> associated with it)
>
> I think this will work much better, and will not feature the same 
> restrictions you have when using upcalls from multiple threads.
>
> Also note that, by using this mechanism, you could, if you wanted, 
> register the upcall MemoryAddress onto a Cleaner, so that the 
> 'freeUpcallStub'  method would be called by the GC when the upcall 
> stub address is no longer reachable, if you wish to leave things to 
> the GC.
>
> Maurizio
>
>>
>>
>>     /**
>>      * Creates a new native memory segment that models a newly 
>> allocated block of off-heap memory with given size (in bytes).
>>      * <p>
>>      * This is equivalent to the following code:
>>      * <blockquote><pre>{@code
>>     allocateNative(bytesSize, 1);
>>      * }</pre></blockquote>
>>      *
>>      * @implNote The *initialization state of the contents of the 
>> block of off-heap memory associated with the returned native memory**
>> **     * segment is unspecified and should not be relied upon*. 
>> Moreover, a client is responsible to call the {@link 
>> MemorySegment#close()}
>>      * on a native memory segment, to make sure the backing off-heap 
>> memory block is deallocated accordingly. Failure to do so
>>      * will result in off-heap memory leaks.
>>      *
>>      * @param bytesSize the size (in bytes) of the off-heap memory 
>> block backing the native memory segment.
>>      * @return a new native memory segment.
>>      * @throws IllegalArgumentException if {@code bytesSize < 0}.
>>      */
>>
>>
>> Cheers,
>>  Michael
>>