Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8050147

StoreLoad barrier interferes with stack usages

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b32
    • CPU:
      x86
    • OS:
      generic

      Backports

        Description

        The issue was originally found in a larger benchmark, but can be also shown with targeted tests.

        In short, on x86, we emit "lock addl %(esp+0), 0" as the substitute for StoreLoad barrier, and while this thing seems faster than "mfence", we interfere with things residing on the top of the stack: call arguments, for one example. The interaction appears to be either the true data dependency via %(esp+0), or the implicit dependency via the cache line containing %(esp+0) locked with lock-prefixed instruction.

        This bug suggests to reconsider the instruction sequence emitted for the StoreLoad barrier, see comments.

          Issue Links

            Activity

            Hide
            shade Aleksey Shipilev added a comment - - edited
            Benchmark:
             http://cr.openjdk.java.net/~shade/8050147/VolatileBarrierBench.java

            Runnable JAR:
             http://cr.openjdk.java.net/~shade/8050147/benchmarks.jar

            I hacked VM into doing five variants, and it does seem to confirm the hypothesis that adding up something on the stack top interferes with stack users. It seems dodging a full long backwards helps to alleviate the issue.

            * Original
             result: 2409.020 +- 1.154 ns/op
             profile: http://cr.openjdk.java.net/~shade/8050147/orig.perfasm

            * "lock addl %(rsp-8), 0", this breaks data dependency, touches the stack backwards
             result: 1512.631 +- 9.555 ns/op
             profile: http://cr.openjdk.java.net/~shade/8050147/rsp-minus-8.perfasm

            * "lock addl %(rsp+8), 0", this breaks data dependency, touches the stack forward
             result: 1944.047 +- 8.588 ns/op
             profile: http://cr.openjdk.java.net/~shade/8050147/rsp-plus-8.perfasm

            * "lock addl %(rsp-72), 0", this also hopefully unties the cache line, touches the stack backwards
             result: 1531.660 +- 3.578 ns/op
             profile: http://cr.openjdk.java.net/~shade/8050147/rsp-minus-72.perfasm

            * "lock addl %(rsp+72), 0", this also hopefully unties the cache line, touches the stack forward
             result: 1726.412 +- 293.925 ns/op
             profile: http://cr.openjdk.java.net/~shade/8050147/rsp-plus-72.perfasm

            * "mfence"
             result: 2864.449 +- 19.562 ns/op
             profile: http://cr.openjdk.java.net/~shade/8050147/mfence.perfasm

            Touching the stack forward seems to be as dangerous as original: there could be something spilled on stack,
            or other arguments read from there.
            Show
            shade Aleksey Shipilev added a comment - - edited Benchmark:   http://cr.openjdk.java.net/~shade/8050147/VolatileBarrierBench.java Runnable JAR:   http://cr.openjdk.java.net/~shade/8050147/benchmarks.jar I hacked VM into doing five variants, and it does seem to confirm the hypothesis that adding up something on the stack top interferes with stack users. It seems dodging a full long backwards helps to alleviate the issue. * Original  result: 2409.020 +- 1.154 ns/op  profile: http://cr.openjdk.java.net/~shade/8050147/orig.perfasm * "lock addl %(rsp-8), 0", this breaks data dependency, touches the stack backwards  result: 1512.631 +- 9.555 ns/op  profile: http://cr.openjdk.java.net/~shade/8050147/rsp-minus-8.perfasm * "lock addl %(rsp+8), 0", this breaks data dependency, touches the stack forward  result: 1944.047 +- 8.588 ns/op  profile: http://cr.openjdk.java.net/~shade/8050147/rsp-plus-8.perfasm * "lock addl %(rsp-72), 0", this also hopefully unties the cache line, touches the stack backwards  result: 1531.660 +- 3.578 ns/op  profile: http://cr.openjdk.java.net/~shade/8050147/rsp-minus-72.perfasm * "lock addl %(rsp+72), 0", this also hopefully unties the cache line, touches the stack forward  result: 1726.412 +- 293.925 ns/op  profile: http://cr.openjdk.java.net/~shade/8050147/rsp-plus-72.perfasm * "mfence"  result: 2864.449 +- 19.562 ns/op  profile: http://cr.openjdk.java.net/~shade/8050147/mfence.perfasm Touching the stack forward seems to be as dangerous as original: there could be something spilled on stack, or other arguments read from there.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51e474c55d20
            User: drchase
            Date: 2014-09-04 17:50:17 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51e474c55d20 User: drchase Date: 2014-09-04 17:50:17 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/51e474c55d20
            User: lana
            Date: 2014-09-24 20:47:23 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/51e474c55d20 User: lana Date: 2014-09-24 20:47:23 +0000

              People

              • Assignee:
                shade Aleksey Shipilev
                Reporter:
                shade Aleksey Shipilev
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: