RFR: jsr166 jdk integration 2018-02
david.holmes at oracle.com
Fri Feb 9 06:39:48 UTC 2018
On 9/02/2018 3:35 PM, Martin Buchholz wrote:
> On Thu, Feb 8, 2018 at 8:39 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
> 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!
> I've argued similarly even in the past month that "this" should always
> remain reachable while a method on "this" is executing, in the presence
> of a finalize method. (It would also be nice if java language scope
> mapped to reachability range, but that information is already lost in
> the translation to bytecode.) But apparently it is quite a burden on
> any implementation to ensure reachability, especially after inlining.
> We've never had a report of this problem occurring in practice.
Well at least it's only an issue if there does exist a finalize() method
that could interfere with the executing method. I have to assume that
somehow the VM is clever enough that if 'this' is in a register and we
will later access a field at this+offset, that the GC will not free the
memory used by 'this'.
Somewhat ironic we add the reachabilityFence in the same changeset that
removes the action of the finalize() method in TPE. (But of course the
ExecutorService passed to the delegating service may still have one.)
More information about the core-libs-dev