RFR: jsr166 jdk integration 2018-02
David Holmes
david.holmes at oracle.com
Fri Feb 9 04:39:12 UTC 2018
Hi Martin,
On 9/02/2018 2:07 PM, Martin Buchholz wrote:
>
>
> On Thu, Feb 8, 2018 at 7:39 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> On 9/02/2018 11:19 AM, Martin Buchholz wrote:
>
> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
> <http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html>
>
> 8190324: ThreadPoolExecutor should not specify a dependency on
> finalization
> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ThreadPoolExecutor-finalize/index.html
> <http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ThreadPoolExecutor-finalize/index.html>
> https://bugs.openjdk.java.net/browse/JDK-8190324
> <https://bugs.openjdk.java.net/browse/JDK-8190324>
>
>
> Looks okay.
>
> Another set of uninteresting changes, some suggested by intellij:
>
> 8195590: Miscellaneous changes imported from jsr166 CVS 2018-02
> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
> <http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html>
> https://bugs.openjdk.java.net/browse/JDK-8195590
> <https://bugs.openjdk.java.net/browse/JDK-8195590>
>
>
> Hmmmm ... a summary of changes in the bug report would be nice.
>
>
> Done.
>
> I don't find the addition of reachability fences uninteresting
> though. Why are they needed in those specific cases?
>
>
> perhaps the standard should be for every method of a class with a
> finalizer to have reachabilityFence(this) at the end?
>
> Imagine
>
> newSingleThreadExecutor().execute(someTask);
>
> Is is unlikely but possible for the "instant garbage" executor to be
> finalized while super.execute is in progress, causing failure with
> RejectedExecutionException because the delegatee is already shutdown.
Wow! DelegatedExecutorService doesn't even have a finalize() method that
does a shutdown. So we have to put the reachabilityFence in it to
prevent the delegatee from becoming unreachable due to the delegator
becoming unreachable!
This whole notion that "this" can be unreachable whilst a method on it
is still executing is just broken - it's an unusable programming model.
Any code that does "new Foo().bar()" could fail unless Foo.bar() has a
reachability fence in it. :( Sheesh!
Cheers,
David
More information about the core-libs-dev
mailing list