RFR: jsr166 jdk integration 2018-02
david.holmes at oracle.com
Fri Feb 9 04:39:12 UTC 2018
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:
> 8190324: ThreadPoolExecutor should not specify a dependency on
> Looks okay.
> Another set of uninteresting changes, some suggested by intellij:
> 8195590: Miscellaneous changes imported from jsr166 CVS 2018-02
> Hmmmm ... a summary of changes in the bug report would be nice.
> 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?
> 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
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!
More information about the core-libs-dev