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

Shenandoah: asynchronous object/region pinning

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 8-shenandoah, 11-shenandoah, 14
    • Fix Version/s: 14
    • Component/s: hotspot
    • Subcomponent:
      gc
    • Resolved In Build:
      b20

      Description

      Originally reported here:
       https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010772.html

      The easiest reproducer is this:
        https://cr.openjdk.java.net/~shade/8232575/GZIPUncompressBench.java
        https://cr.openjdk.java.net/~shade/8232575/benchmarks.jar

      With current jdk/jdk:

      Parallel, 1 thread: 111.951 ± 4.628 us/op
      Parallel, 16 threads: 149.951 ± 3.555 us/op
      Shenandoah, 1 threads: 141.543 ± 0.280 us/op
      Shenandoah, 16 threads: 1451.914 ± 51.406 us/op ; <---- huge scalability bottleneck

      This is ruled to be the contention on the lock that guards the transition to "Pinned" state for the region. Shenandoah can be much smarter about that.

      With this proof-of-concept patch:
       https://cr.openjdk.java.net/~shade/8232575/webrev.01/

      Shenandoah, 1 threads: 111.997 ± 3.213 us/op ; <--- matches Parallel
      Shenandoah, 16 threads: 151.777 ± 3.511 us/op <--- matches Parallel

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: