MemorySegment.close(), threads
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Jan 16 11:36:36 UTC 2020
>>
> 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
>
More information about the panama-dev
mailing list