RFR: jsr166 jdk integration 2018-02

[Hans Boehm]

On Thu, Feb 8, 2018 at 9:35 PM, Martin Buchholz <martinrb at google.com> wrote:

> On Thu, Feb 8, 2018 at 8:39 PM, David Holmes <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.
>

The downside of treating "this" specially is that it makes it even harder
to explain the other cases, e.g. when the object being finalized
prematurely was an explicit parameter, or perhaps even the result of a
factory method.

The presence of a finalize() method seems to be less and less of an
indication of whether this treatment is needed. It's harder to determine
that objects are being monitored by a Cleaner or PhantomReference. But the
issues are exactly the same.

In my opinion, we're basically stuck with two ways to fix this:

1) Disallow visible dead reference elimination altogether.

2) Require the programmer to specify when it's problematic.

I think (1) is very intrusive, and probably impractical at this point,
since it requires preservation of reliable scope information throughout the
tool chain. ReachabilityFence() is an unexpectedly clumsy way to do (2),
since the same information needs to be repeated for every method.

My sense is that this does happen in practice, but indeed extremely rarely.
One of my former HP colleagues pointed out to me, shortly after my original
JavaOne talk on this topic, that this explained a problem they had been
trying to track down. I haven't heard of other instances. I suspect they
are generally written off as "alpha particles" or "gc bugs" or the like,
especially since, in the native code case, they are likely to show up later
as heap corruption, and are often essentially untraceable.