JDK-8055183 : Decide whether this can be GCed
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2014-08-15
  • Updated: 2016-04-12
  • Resolved: 2016-04-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Duplicate :  
JDK-8133348 - Reference.reachabilityFence
Relates :  
JDK-8046178 - JEP 188: Java Memory Model Update
Relates :  
JDK-8133348 - Reference.reachabilityFence
Description
It turned out during discussion about lightweight finalization (see JDK-8051843) that people often blame finalization for misbehavior which is not necessarily related to finalization, rather to VM behavior. In my opinion (as expressed at http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028215.html ) it boils down to question whether following method can finish or not:

    private void gcThis() {
        Reference<?> ref = new WeakReference<>(this);
        while (ref.get() != null) {
            System.gc();
        }
        System.err.println("ref is gone: " + ref);
    }

my personal suggestion is that it should never finish, however I am not the right person to decide that. Rather I just report this issue to track the decision made by others. I just want to express my developer wish: sometimes I want "this" to not be GCed while its instance method is running and it would be nice to have cross VM way to enforce that.
Comments
JDK-8133348 Reference.reachabilityFence Provides the mechanism to keep a reference reachable. This issue can be closed as a 'duplicate'.
18-02-2016
We think it is useful to keep this RFE open as a reminder. ILW (as far as we understand the issue): Impact: medium -> annoying behavior of the VM which is covered by the spec Likelihood: medium -> problem (or enhancement) would be nice to have sometimes Workaround: high -> none. => P3
18-08-2014
Doug Lea responded on the core-libs-dev mailing list: > I believe that either behavior is legal under current JLS specs. See > in particular sec 12.6.2 > (http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.6.2) > Among the few guaranteed ways to ensure that "this" is kept reachable > (and not GCable) is to write "this" somewhere after its fields are > used. In other cases, a reference may or may not be kept reachable in > any given JVM, depending on safepoint schemes, whether the collector > is concurrent, etc. > The surprisingness of the rules, and the lack of any other means of > control have been known issues for years. Because reachability > interacts with other memory ordering rules (for example, just to > explain what "after" means above), we are discussing changes as part > of the JMM revisions. (See archives at > http://mail.openjdk.java.net/pipermail/jmm-dev/) These extend some > previous discussions and proposals that we never pushed through for > JDK7. > Minimally, there should be a means of forcing reachability without > forcing writes. One (old, unshipped) version of this can be found at > http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html > As first discovered by Hans Boehm, it just so happens that one way to > implement the equivalent of reachabilityFence(x) even now is > "synchronized(x) {}". (See Hans's 2005 JavaOne slides at > http://hboehm.info/misc_slides/java_finalizers.pdf) But I suspect that > a less weird and more efficient intrinsic will be introduced for JDK9. > Beyond this, we are discussing prospects for extending reachability > without programmers needing to use lots of reachabilityFences, > possibly by introducing an @Finalized annotation to automate common > cases. I don't think there is consensus on this yet, in part because > there does not seem to be a way to do this that eliminates all > possible surprises/errors. > In the mean time, your RFE JDK-8055183 > (https://bugs.openjdk.java.net/browse/JDK-8055183) seems to overlap > existing JMM revision efforts. I don't know whether you'd like to > keep it open as a reminder, or just close it. > -Doug
15-08-2014