MemorySegment.close(), threads

[Ty Young]

On 1/15/20 5:38 AM, Maurizio Cimadamore wrote:
>
> On 15/01/2020 11:00, Michael Zucchi wrote:
>>
>> Evening,
>>
>> Has it been considered to have MemorySegment.close() work on any thread?
>>
>> As far as I can tell doing so wouldn't impact the other checks on 
>> usage and it would still 'safely' throw appropriate exceptions for 
>> incorrect use for anything that erroneously retained a stale reference.
>>
>> This would enable a couple of common processing flows which are 
>> currently impossible such as worker threads or parallel streams 
>> returning results, and using reference queues for any object that 
>> uses a java-allocated memory segment. This doesn't really occur very 
>> often as such resources are typically allocated by C (being 
>> unbeholden to such restrictions), and in the worst case values can be 
>> copied by hand-marshalling to pojos.
>
> You can share a segment across multiple threads using the 
> MemorySegment::acquire method. The workflow is as follows:
>
> 1) master thread creates a segment
> 2) many worked threads acquire the segment
> 2a) at this point master thread can no longer close the segment (since 
> there's threads using it)
> 3) worked threads do work on their segment (slice?) and then close 
> their acquired segment - closing an acquired segment does NOT deallocate
> 4) once all the acquired segments have been closed by the worked 
> threads, the master thread can proceed closing the original segment 
> for good (which will deallocate)
>
> The main reason for enforcing such a workflow (or _any_ workflow) is 
> that we want to avoid race conditions where a thread accesses a 
> segment while another closes it, which, again would lead potentially 
> to a hard VM crash (which the API wants to avoid).
>
> Slight variations on this protocol have been suggested during the code 
> review for JDK 14 integration where all threads are on an equal 
> footing, and the last one closing the segment triggers deallocation. 
> This is also possible to achieve, we need real world validation to 
> guide us in picking which flavor would be more useful most of the times.
>

FWIW, all threads having equal footing sounds a lot better to me both 
from a logical and technical standpoint. There is zero guarantee that 
the main/master thread is going to be the first one that creates the 
segments and to enforce such a model feels like Project Panama is trying 
to dictate how people should write their own code for arbitrary reasons.


How can you even tell apart the master thread from a worker thread? No 
methods AFAIK exists right now, only the ability to acquire the segment 
and a boolean check to see if the current thread can access the segment. 
Previously with the Scope API you had a hierarchy of memory allocation 
units but with Memory Access you don't...


> Maurizio
>
>>
>> Regards,
>>  Michael
>>