Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b103

      Description

      This RFE covers the implementation of Fences.reachabilityFence, as suggested by Doug Lea.

      Proof of concept, plus tests:
       http://cr.openjdk.java.net/~shade/8133348/

        Issue Links

          Activity

          Hide
          psandoz Paul Sandoz added a comment - - edited
          Notes from Vitaly on possible key performance issues with the current implementation approach:

            http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020366.html
            http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020367.html

          1) current impl/prototype is purposely barred from inlining - this will be a compiler optimization fence, particularly bad in loops

          2) the expected "try { ... use(r) ... } finally { reachabilityFence(r); }" idiom will significantly increase bytecode size, possibly impacting inlining.

          3) what impact will this have, if any, on register allocation when a ref's lifetime is artificially extended without any "real" use. The thinking here is compiler should spill it and never reload, but it was unclear if it will do the right thing in its current form.

          Discussion thread on concurrency-interest:

            http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014609.html
          Show
          psandoz Paul Sandoz added a comment - - edited Notes from Vitaly on possible key performance issues with the current implementation approach:    http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020366.html    http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020367.html 1) current impl/prototype is purposely barred from inlining - this will be a compiler optimization fence, particularly bad in loops 2) the expected "try { ... use(r) ... } finally { reachabilityFence(r); }" idiom will significantly increase bytecode size, possibly impacting inlining. 3) what impact will this have, if any, on register allocation when a ref's lifetime is artificially extended without any "real" use. The thinking here is compiler should spill it and never reload, but it was unclear if it will do the right thing in its current form. Discussion thread on concurrency-interest:    http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014609.html
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/827ce3d74163
          User: psandoz
          Date: 2015-12-14 12:47:57 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/827ce3d74163 User: psandoz Date: 2015-12-14 12:47:57 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/827ce3d74163
          User: lana
          Date: 2016-01-27 21:42:04 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/827ce3d74163 User: lana Date: 2016-01-27 21:42:04 +0000

            People

            • Assignee:
              psandoz Paul Sandoz
              Reporter:
              shade Aleksey Shipilev
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: