Question on recommended practice with FMA

[Maurizio Cimadamore]

On 14/04/2021 19:45, leerho wrote:
> I am using Java 16 GA for now to migrate our entire library as I don't 
> want to track a moving target while I'm doing this migration.  And, I 
> am hoping that the migration from 16 to 17 won't be too severe and 
> certainly easier than the migration from 8 to 16.
>
> Nonetheless, with the code snippet I gave above.  I would think that a 
> simple slice view should never trigger a resource-leak warning.  The 
> slice view object would go out of scope with the closing brace and 
> would be collected by the GC.  With the code as it is now, where every 
> new Segment is AutoCloseable, and to avoid the warnings, I have to 
> explicitly refactor the code to allow me to close segments that 
> shouldn't need closing, which is a PITA :)
Sure - but please understand that we have zero control over what Eclipse 
decide to flag (or not to flag) as a warning. "Lint"-style warnings are 
optional, and vary across different compiler. As Remi suggested, this 
seems to be an issue in the Eclipse compiler being overly pedantic - we 
can't help, sorry.
>
> I do wonder why you even allow the close() on a slice view to close 
> the underlying, parent segment.  I would think that it is the 
> responsibility of the owner of the originating segment to close.  So, 
> in my mind the ability to close should never be delegated by default 
> and only delegated with an explicit handoff.

This was one of the issue with the API in 16 - there is a tension 
between use cases:

* some want to view a slice as - well, just a dependent segment; so, as 
you say, it doesn't make sense to "close" a slice
* in other cases (e.g. for alignment reasons) you might allocate a 
segment and then slice it, and keep working with it - e.g. the slice 
becomes the real segment

>
> In my Memory package I solved this problem by assigning the close 
> responsibility of the Segment to a Handle. These Handles were only 
> used where AutoCloseable was really necessary, e.g., segments of 
> off-heap, or memory-mapped files.  When a segment wraps a heap-array 
> or a ByteBuffer, AC is not needed.  As a result, when passing a 
> segment to another method the close() does not go with it.
>
> I thought at some point you were going to use handles.  No?

The discussion moved on a bit from the handle proposal. The email where 
I introduce the proposal is this:

https://inside.java/2021/01/25/memory-access-pulling-all-the-threads/

Basically, instead of having an handle abstraction, we now have an 
explicit abstraction (ResourceScope) which lets us speak about the 
lifecycle of a memory segment (or any other resource, like upcall 
stubs). This scales better, as you can allocate multiple segments under 
the same scope (so that they are closed at once) which is very useful in 
real world applications.

This gives you a much simpler MemorySegment that is no longer 
AutoCloseable (but ResourceScope is). For practicality, a segment still 
has a link to its owning scope - so, if you want you can still shoot 
yourself in the foot and call scope().close() on a slice - but at least 
the API makes it clear that a scope is a shared beast - and closing a 
scope will have consequences which goes beyond that of the single 
resource (in the general case).

Overall, I think the new changes bring the API not too far from the 
handle-based API you had, but since we have to think about interop with 
native app (e.g. foreign linker API) we landed on a slightly different spot.

Cheers
Maurizio


>
> (Forgive me, I haven't followed all of the changes you have made since 
> 16 GA :) )
>
> Lee.
>
> On Wed, Apr 14, 2021 at 3:52 AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>
>     On 14/04/2021 11:49, Maurizio Cimadamore wrote:
>     > Agree - this seems odd. I'm not super sure as to why that check was
>     > added to memory segment calls and what it does precisely
>     (Eclipse uses
>     > a different compiler for generating this warnings than javac,
>     which is
>     > the compiler that comes with OpenJDK).
>     >
>     > Maurizio
>
>     Ok - it seems like the warning blindly assumes that every new
>     AutoCloseable that is obtained must be closed.
>
>     This probably means that you are using the Java 16 API, not the
>     new one?
>     But, in any case, even in the new API there might be issue when using
>     implicit resource scopes (as these are managed by the GC and not
>     closed
>     by clients).
>
>     Maurizio
>