[foreign-jextract] Closing sliced segment closes original segment

[Filip Krakowski]

Hi,

thanks for the detailed explanation! I have not yet thought of the case 
of aligned memory. Here it definitely makes sense to close the parent 
segment, otherwise memory leaks could occur.

I will try do adapt my code, so that it doesn't try to close 
MemorySegments obtained through field accesses.

Best regards,
Filip

On 8/4/20 4:24 PM, Maurizio Cimadamore wrote:
>
> On 04/08/2020 15:01, Filip Krakowski wrote:
>> I don't know if this makes sense, but I would expect MemorySegments 
>> to behave like (direct) ByteBuffers (slices) in this context, since 
>> the slice's memory is not released automatically (using a Cleaner) 
>> after the slice gets garbage collected. Is there a specific reason as 
>> to why child segments close their parent segments? If I got it right, 
>> the client would need to check if the segment has the CLOSE access 
>> mode set to decide if it may close the segment or not. 
>
> In the byte buffer API, every buffer is managed with a cleaner. A 
> slice is a segment which points to the original buffer, hence keeping 
> it "alive". The memory access API supports deterministic deallocation, 
> so we have to answer a question that the bytebuffer API doesn't have: 
> what should happen when a segment slice is closed? There are three 
> possible answers:
>
> 1) close the original segment
> 2) do nothing
> 3) throw
>
> Now, the general sense, when writing the API, was that clients wanted 
> either (1) or (2,3). That is, there are cases where you really want 
> the slice to act like the real segment, and closing the slice should 
> close the whole thing. This is the case where a segment is created, 
> and maybe, for alignment purposes, a slice of it is taken, and then 
> worked on by a client.
>
> But there are also other cases in which the slices are never really 
> meant to be closed, because the slices are portions of a bigger memory 
> region that is handled somewhere else. In this case clients want 
> either (2) or (3), but never (1), as they do _not_ want the original 
> segment to be closed. We preferred (3) over (2) because the API is in 
> general pretty aggressive in trying to enforce well-formedness of 
> segments invariants - that is, if a segment is non-closeable and you 
> try to close it, we like to report an exception, rather than doing 
> nothing.
>
> An alternative is of course possible, where calling asSlice creates a 
> new segment with its own independent scope, whose cleanup action does 
> nothing. But note that this scope is not really 100% independent: if 
> the main segment is closed, then the slice segment should be reported 
> as closed as well. This is tricky to get right, and in general seems 
> to suggest that a parent segment and all its slices share the _same_ 
> temporal bounds: if the parent segment is closed, then all the slices 
> derived from it should be considered closed too. If you keep pulling 
> on this string, then it follows that closing a slice also results in 
> closing the parent segment (since both share the same temporal bounds) 
> - and the only thing a client can do to protect against this is to 
> remove the CLOSED access mode on the slice. Also, having an API where 
> slicing would result in a new stateful scope being created would 
> prevent any possibility to implement slices with inline types when 
> Valhalla will land. All this seemed to push towards a model where 
> slices are stateless entities which share the temporal bounds with 
> some parent segment.
>
> Maurizio
>
>