RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

[Maurizio Cimadamore]

On 29/04/2020 08:10, Peter Levart wrote:
> Right, as you saw in a private Email, I did exactly that in a revised 
> version (posted below). The spurious ISE may happen but only when 
> close is called prematurely relative to all child scope close(s) that 
> were or are still active. So we could say the other way: if close was 
> not called prematurely, the ISE on acquire would not be spurious - so 
> ordering of close relative to later acquire was wrong anyway and the 
> exception is an "indication" of that wrong ordering
>
> Unless we want to use close() to "probe" the scope whether it is still 
> active or not, I don't think this should present a problem.

One quick comment: unless I'm missing something, this is starting to 
make a pretty strong assumption on how acquire()/close() are going to be 
used. Yes, if acquire() is not exposed to developers (as in the current 
API) and only hidden behind a spliterator, we might get away with this; 
but should we at some point re-introduce some kind of explicit acquire 
mechanism in the API, then such an assumption would not be a fine one to 
make.

Maurizio