[foreign] RFR: native libraries should have a global scope

[John Rose]

On Jul 6, 2018, at 6:15 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> This patch adds a global scope that is shared by all instance of a certain library. The scope is created when an impl for a library interface is requested. A reference cleaner is also used to make sure that the Scope::close method is called when the library class is unloaded.

Yes, this is a good use of scopes, which we've discussed before. I'm very glad
to see it getting fleshed out.

Most Scopes are block Scopes, meaning their lifetime is tied to the execution of a
block of code–a particular block activation, inside a particular frame and thread.

But we need Scopes which are not tied to particular blocks; such non-block Scopes are
global (in some sense) across any particular stack of block activations.

I am sometimes tempted to use the terms "dynamic" and "static", but I think that won't do,
because when talking about *variable name* scopes, the terms dynamic and static (aka
lexical) cut irregularly across our concept of Scoep which applies to *variable lifetimes*,
either in block or or not (globally).

Our Scope API is a bit of a misnomer, since it manages unnamed object entities
by reference, creating and destroying them in a predictably useful manner.  As such
it acts like (and emulates) the processing of named variables in a block-scoped
language.  The technical term "extent" or "lifetime" can be used to specifically
refer to the span of a variable apart from the places where its name is visible.

This article helpfully discusses the relations between scope and extent.
  https://en.wikipedia.org/wiki/Variable_(computer_science)#Scope_and_extent

Sayings like "x goes out of scope when f returns" are catchy, and I've heard them
used to describe the dynamic end of a variable's lifetime.  But the more exactly
correct usage is to say "x is in scope" only when and where an appropriate
name resolution process would connect the string "x" to the right variable.
I don't think I've never heard usages like "x goes out of extent" or "x's extent
ends", despite the more correct use of the word "extent" than "scope".

For us, viewing Scope as a factory for unnamed variables (rather than a
dictionary for names) means that a single Scope can have many variables,
and all of the variables are alive until that Scope is closed.

This leads to some interesting corollaries:

 - Java Scope objects are used to along with Java blocks and variables.
 - In these usages, the Java scopes and variables model foreign (C) blocks and variables.
 - Most Scopes are used with try/finally blocks to track Java block scopes.
 - Some Scopes are needed to correspond to Java global variables.
 - Some global variables have non-trivial lifetimes tied to other global objects, hence our use of Cleaners.

I've mentioned cross-scope operations before; they are tied to this bundle
of corollaries:

 - It makes sense for one Scope to hand off a variable to another Scope (both must be open).
 - Handing off a variable from a short-lived Scope to a long-lived one gives that variable a reprieve.
 - Handing off a variable from a long-lived Scope to a short-lived one hastens that variable's demise.
 - A hand-off between Scopes of unrelated lifetimes simply moves storage management responsibility.
 - Hand-offs can be confined to one thread, in which case they don't need synchronization.
 - Hand-offs not confined to one thread can potentially expose race conditions, and may need fences and/or locks.
 - A Java queue object can usefully be associated with a Scope that manages resources for queued objects.
 - It is natural for a "queue-like" Scope to temporarily "check out" a variable to a block Scope during a (locked/fenced) critical section.
 - It is natural for one "queue-like" Scopes to hand off a variable to another, using either a CAS or an intermediate block Scope.

Our Scope API exists not only to give Java programmers control over variable
lifetimes, but also to manage checks for dangling pointers.  When a Scope is closed,
all of its variables are made inaccessible before they are deallocated.  (If we were
to take those steps in a reverse order, then a race condition could traverse a
dangling pointer.)  The access check on every pointer use therefore checks whether
that pointer's scope is active.

This observation, combined with previous ones, leads to some more corollaries:

 - Access checking a thread-confined variable can be enforced by a simple pointer comparison against the current thread.
 - Scopes which forbid access to *all* threads are useful to exclude races on enqueued native resources.
 - There can be a special bit-bucket Scope which takes variables out of circulation (and then frees their storage).
 - There can be a special Java-heap Scope which keeps variables around until they can't be reached by Java.

Finally, all of the above discussion can be rephrased replacing the API name
"Scope" with a new name like "Lifetime" or "StorageExtent".  As noted above,
that might be more correct when discussing all of the above points.  But I still
like the API name "Scope" because it reads well in Panama user code.

Perhaps the underlying API for managing resource lifetimes/extents should
be called something solemn and correct like "ResourceExtent", while the thing
in user code that shows up today as "Scope" should be called something else,
short and catchy but slightly more correct.  Since we are modeling block scoping
in C (and eventually other languages), maybe we should call that thing Block.
So you do a try-with-resources of a Block, and off you go.  The Block implements
the ResourceExtent protocol.  There are other interesting resource extents
out there which are *not* blocks.  Today we call all of them Scopes.  Although
it is the Java style to lump multiple related concepts under a single name,
I'd support a split between Block and ResourceExtent if we wish to make
more precise distinctions between (a) our modeling of block scopes and
(b) the complexities of resource management.

— John