On Thu, Feb 8, 2018 at 7:39 PM, David Holmes <david.hol...@oracle.com> wrote:
> On 9/02/2018 11:19 AM, Martin Buchholz wrote: > >> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integr >> ation/overview.html >> >> 8190324: ThreadPoolExecutor should not specify a dependency on >> finalization >> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integr >> ation/ThreadPoolExecutor-finalize/index.html >> 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-integr >> ation/miscellaneous/index.html >> 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.
