DirectByteBuffers and reachabilityFence

classic Classic list List threaded Threaded
148 messages Options
1 ... 5678
Reply | Threaded
Open this post in threaded view
|

Re: DirectByteBuffers and reachabilityFence

Justin Sampson
David Holmes wrote:

> Here's another nasty little reachability/finalize example:
>
> https://bugs.openjdk.java.net/browse/JDK-8145304

Interesting! The use case is a bit odd -- I mean, why bother with an
executor when it's not going to be used for anything but a single
task? -- but as a general design issue, is this an example of the
kind of thing that should never have been using finalization in the
first place? I.e., we all know that finalization is problematic, but
it seems like it's occasionally useful for managing native resources
if done carefully. This is just a thread pool. If the programmer
never explicitly shuts down the thread pool, shouldn't it just be
left running? It's their own fault, after all, for not using the API
properly, and the result of not shutting down during finalization is
merely a performance issue, not a correctness issue.

Cheers,
Justin

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: DirectByteBuffers and reachabilityFence

Paul Sandoz
In reply to this post by Andrew Haley

On 15 Dec 2015, at 14:54, Andrew Haley <[hidden email]> wrote:

On 12/15/2015 12:37 PM, Vitaly Davidovich wrote:
To be fair, no empirical evidence has been presented; there is speculation
of scenarios it may hurt but nothing concrete.

Exactly.  That was the answer!

I also think the bigger obstacle to changing this behavior is getting all
the different JVM implementations modified and not really the performance
impact.

Yes, it's political as well.  reachabilityFence() is a great start.


The current API and implementation (with known limitations) is now in hs-comp:


It will eventually wind it’s way into a JDK EA build but i don’t know exactly when.

Paul.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DirectByteBuffers and reachabilityFence

thurstonn
In reply to this post by Martin Buchholz-3
Ahh, yes.  You're right.
The outer ES becomes unreachable while the delegate's #submit is executing.
And the outer ES finalize (indirectly) ->
   delegate.shutdown()

hence the race and the rejected submission


Martin Buchholz-3 wrote
I just added this comment to
https://bugs.openjdk.java.net/browse/JDK-8145304

Part of the problem is that there are two finalize methods in play here.
The implementation does

    public static ExecutorService newSingleThreadExecutor() {
        return new FinalizableDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,

so the outer executor may get finalized while methods on the inner are
still executing.

Not sure of the motivation for the finalization strategy here.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: DirectByteBuffers and reachabilityFence

Doug Lea
In reply to this post by Martin Buchholz-3
On 12/15/2015 12:43 PM, Martin Buchholz wrote:

> Part of the problem is that there are two finalize methods in play here.
> The implementation does
>
>      public static ExecutorService newSingleThreadExecutor() {
>          return new FinalizableDelegatedExecutorService
>              (new ThreadPoolExecutor(1, 1,
>
> so the outer executor may get finalized while methods on the inner are
> still executing.
>
> Not sure of the motivation for the finalization strategy here.

See http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6399443
and concurrency-interest discussion in March 2006 with subject
   Finalization changes to DelegatedExecutorService
http://cs.oswego.edu/pipermail/concurrency-interest/2006-March/thread.html

Without this, some users were leaking Executors/Threads.
This is arguably not our (j.u.c) problem.
But after some resistance, we decided to add the finalizer.
With it, users may encounter surprisingly early shutdown without
reachabilityFence.

-Doug





_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: DirectByteBuffers and reachabilityFence

thurstonn
So will DelegatedExecutorService be refactored to include reachabilityFence() calls where appropriate?
e.g.

public Future<?> submit(Runnable task) {
            return e.submit(task);
        }

becomes

public Future<?> submit(Runnable task)
{
            Future<?> result = e.submit(task);
            reachabilityFence(this);
            return result;
}

that would ameliorate (although not eliminate) the issue

Doug Lea wrote
On 12/15/2015 12:43 PM, Martin Buchholz wrote:
> Part of the problem is that there are two finalize methods in play here.
> The implementation does
>
>      public static ExecutorService newSingleThreadExecutor() {
>          return new FinalizableDelegatedExecutorService
>              (new ThreadPoolExecutor(1, 1,
>
> so the outer executor may get finalized while methods on the inner are
> still executing.
>
> Not sure of the motivation for the finalization strategy here.

See http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6399443
and concurrency-interest discussion in March 2006 with subject
   Finalization changes to DelegatedExecutorService
http://cs.oswego.edu/pipermail/concurrency-interest/2006-March/thread.html

Without this, some users were leaking Executors/Threads.
This is arguably not our (j.u.c) problem.
But after some resistance, we decided to add the finalizer.
With it, users may encounter surprisingly early shutdown without
reachabilityFence.

-Doug





_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: DirectByteBuffers and reachabilityFence

Hans Boehm
In reply to this post by David Holmes-6
My vague recollection is also that there should have been a statement preventing finalization before constructor completion.  I'm actually no longer sure how much it matters.  I think 12.6.2 ensure that the finalizer must see all non-finalizer writes to the object.  Thus I think it must see an object that looks more or less initialized.  In the new world, basically every method, probably including the constructor, that uses a field cleaned up by a finalizer should use an explicit reachabilityFence.

I suspect that in the long run we essentially just want to say that the last reachabilityFence happens before the finalizer, and lose the rest of 12.6.2.  Almost no finalizer works without reachabilityFence anyway.

Note that "this" is really not special here.  A great (bad?) example is Android's BigInteger implementation that wraps a native bignum implementation.  The finalizer deallocates the native object.  If you look at something like the add() method, "this" and the method argument are entirely symmetric.  Either would be subject to premature finalization of we didn't work around the issue in the compiler.

On Thu, Dec 10, 2015 at 1:06 PM, David Holmes <[hidden email]> wrote:
David M. Lloyd writes:
>
> On 12/09/2015 07:44 PM, David Holmes wrote:
> > To be clear, I missed this later assertion:
> >
> >> In summary, we agree that an object can _become finalizable_ before
> >> completion of its constructor, if the Object constructor completed
> >> normally and the object is otherwise no longer reachable.
> >
> > No! The object should not be able to become finalizable until after
> all its
> > constructors have completed, and then it becomes unreachable.
>
> Is this your view of the existing world, or what you are proposing be
> changed?  I'm losing track of what's what in this discussion. :-)

This is how the existing world should have been if the JLS update had not
been snafu'd. Justin would argue it should be the current state regardless
due to happens-before definition. Regardless the JVM does not currently
implement this.

David H.


> --
> - DML
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: DirectByteBuffers and reachabilityFence

thurstonn
In reply to this post by Paul Sandoz
If possible, it would be convenient if #reachabilityFence were defined as varargs:

public static void reachabilityFence(Object...  refs)

as there are many cases (e.g. Hans Boehm provides one in this thread) where one would want to extend reachability to a set of objects to the same point.  I wouldn't think that any ordering guarantee need to be preserved in the case where multiple args were passed

I don't know the effect that might have upon the compiler
Reply | Threaded
Open this post in threaded view
|

Re: DirectByteBuffers and reachabilityFence

Chris Vest
Only if we never have to pay the cost of allocating the arguments array.

Cheers,
Chris

On 17 Dec 2015, at 15:54, thurstonn <[hidden email]> wrote:

If possible, it would be convenient if #reachabilityFence were defined as
varargs:

public static void reachabilityFence(Object...  refs)

as there are many cases (e.g. Hans Boehm provides one in this thread) where
one would want to extend reachability to a set of objects to the same point.
I wouldn't think that any ordering guarantee need to be preserved in the
case where multiple args were passed

I don't know the effect that might have upon the compiler



--
View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/DirectByteBuffers-and-reachabilityFence-tp12935p13092.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
1 ... 5678