JEP draft: Scope Locals

Fri May 14 23:28:21 UTC 2021

What about cleanup of the scoped objects?  For example, how do I ensure
close() or some cleanup method is called at the right time on the scoped
object?  Do I need to use a Weak/Soft/PhantomReference and a ReferenceQueue
to track the object?  Do I use Cleaner?  Does the object need to implement
finalize()... hopefully not?

On Fri, May 14, 2021 at 4:56 PM Mike Rettig <mike.rettig at gmail.com> wrote:

> On Fri, May 14, 2021 at 4:39 PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
> > The lifecycle is bounded by the duration of the Runnable passed to the
> > `run()` method.
> >
> > In the simple case, with no inheritance and no snapshotting:
> >
> >     ScopedLocal.where(x, xExpr).run(r)
> >
> > the lifecycle of the binding starts when we enter r, and ends when we
> > return from r.
> >
> The root scoping is trivial but the interesting parts of the life cycle are
> with nested scopes.
>
>
> >
> > With snapshotting, the answer is the same, just less obviously so.  If I
> > take a snapshot of a set of variables, we're not in a scope yet; we'll
> > enter a new scope when we use that snapshot to run a task, possibly
> > multiple times.
> >
> > With inheritance, it is possible that the child thread can live longer
> > than the lifetime of the task that spawned it; this is something we hope
> we
> > can avoid through _structured concurrency_ -- that the inheritance is
> > restricted to cases where we can prove the lifetime of the parent is
> longer
> > than the lifetime of the child.  There's more work to be done here.
> >
> > To be explicit, the two assumptions we need in order to avoid people
> > shooting their feet are:
> >
> >  - ScopeLocal values are effectively final "all the way down".  We can't
> > enforce this, but if users had to synchronize when accessing the state of
> > scoped locals, then someone made a big mistake.  (This joins a very long
> > list of mutability bugs we can't prevent but for which we have to
> > communicate to users what they shouldn't be doing, not unlike "don't
> modify
> > the source of the stream while traversing it.")
> >
> >  - When inheriting, the parent must outlive the child.
> >
>
> With life cycles this is much easier to handle and certainly doesn't
> require the parent outliving the child. Ideally the life cycle itself could
> include a callback of when all scopes are closed. For example this would
> make it easy to create a database pool and create connections as tasks
> require them. The connections could be returned at the end of each scope
> and then the pool could be closed when all scopes complete.
>
>
> >
> >
> > When these assumptions hold, understanding the lifecycle is trivial.
> >
>
> How so? How do I know if a snapshot of my variable has occurred? How do I
> know if my variable has been passed to a different thread? How do I know if
> there are any scopes still active? As a framework designer, I don't want to
> have to add a requirement that users always call the start and end of scope
> methods so I know the lifecycle. A proper implementation makes everything
> transparent to the user of the scoped variable and gives enough control to
> the instantiator of the scoped variable to control its usage.
>
> The life cycle (especially across threads) of a scoped variable is far more
> powerful than standalone scoped variables and I can think of many ways to
> use it.  Most importantly if the jvm can provide the lifecycle of scoped
> variables from parent thread to any child threads (or tasks) then many very
> complicated concurrency problems can be solved in very elegant ways.
>
>
> >
> >
> >
> >
> > On 5/14/2021 3:19 PM, Mike Rettig wrote:
> >
> > I don't see a way to capture the lifecycle of the scoped variable. I
> think
> > for framework designers it's going to be important to know the life cycle
> > of the scoped variable especially with snapshotting and inheritance.  The
> > lack of a defined life cycle for thread locals is one of the many reasons
> > why it should be avoided. If scoped locals have a well defined and
> > comprehensive life cycle then it will make working with them much easier
> > (especially when many threads are involved).
> >
> > interface ScopedVariableLifecycle<T> {
> >    ScopedVariable<T> begin();
> > }
> >
> > interface ScopedVariable<T> {
> >    T get();
> >    void end();
> >
> >    Optional<ScopedVariableLifecycle<T>> createForChildScope();
> >    Optional<ScopedVariableLifecycle<T>> createSnapshot();
> > }
> >
> > static final ScopeLocal<MyType> x = ScopeLocal.forType(MyType.class);
> >
> > //most scoped variables will probably use the standard singleton
> > implementations.
> >
> > ScopedLocal.where(x, new Singleton(new MyType()));
> >
> > ScopedLocal.where(x, new InheritableSingleton(new MyType()));
> >
> >
> > //a custom lifecycle (e.g. database connection that is opened on first
> > access and closed at the end of the scope).
> >
> > ScopedLocal.where(x, new MyScopedVariableLifecycle());
> >
> >
> > On Wed, May 12, 2021 at 10:15 AM Andrew Haley <aph at redhat.com> <
> aph at redhat.com> wrote:
> >
> >
> > There's been considerable discussion about scope locals on the loom-dev
> > list,
> > and it's now time to open this to a wider audience. This subject is
> > important
> > because. although scope locals were motivated by the the needs of Loom,
> > they
> > have many potential applications outside that project.
> >
> > The draft JEP is at
> > https://bugs.openjdk.java.net/browse/JDK-8263012
> >
> > I've already received some very helpful suggestions for enhancements to
> > the API, and it'll take me a while to work through them all. In
> particular,
> > Paul Sandoz has suggested that I unify the classes Snapshot and Carrier,
> > and it will take me some time to understand the consequences of that.
> >
> > In the meantime, please have a look at the JEP and comment here.
> >
> >
> > For reference, earlier discussions are at
> >
> https://mail.openjdk.java.net/pipermail/loom-dev/2021-March/002268.htmlhttps://mail.openjdk.java.net/pipermail/loom-dev/2021-April/002287.htmlhttps://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html
> >
> > --
> > Andrew Haley  (he/him)
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com> <https://www.redhat.com>
> https://keybase.io/andrewhaley
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >
> >
> >
> >
> >
> >
>