Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P3
    • Resolution: Duplicate
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
      gc
    • CPU:
      generic
    • OS:
      generic

      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.

        Issue Links

          Activity

          Hide
          ehelin Erik Helin added a comment -
          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
          Show
          ehelin Erik Helin added a comment - 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
          Hide
          tschatzl Thomas Schatzl added a comment -
          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

          Show
          tschatzl Thomas Schatzl added a comment - 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
          Hide
          rriggs Roger Riggs added a comment -
          JDK-8133348 Reference.reachabilityFence
          Provides the mechanism to keep a reference reachable.

          This issue can be closed as a 'duplicate'.
          Show
          rriggs Roger Riggs added a comment - JDK-8133348 Reference.reachabilityFence Provides the mechanism to keep a reference reachable. This issue can be closed as a 'duplicate'.

            People

            • Assignee:
              dl Doug Lea
              Reporter:
              jtulach Jaroslav Tulach
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: