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

Memory serialization page can become a bottleneck

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 9
    • Fix Version/s: 12
    • Component/s: hotspot
    • Labels:

      Description

      When threads transition state to/from native code they use the memory_serialization_page as a means of performing memory synchronization. Due to the use of a single 4K page, and the requirement for 128byte alignment this is limited to 32 distinct slots. Combined with a poor hashing function we can get excessive contention on these slots and encounter a performance bottleneck.

        Issue Links

          Activity

          Hide
          dholmes David Holmes added a comment -
          Deferring to 11 at this time.
          Show
          dholmes David Holmes added a comment - Deferring to 11 at this time.
          Hide
          dholmes David Holmes added a comment -
          Is this issue going to be used to remove all the code related to the !UseMembar code paths? i.e. to actually Obsolete UseMembar in JDK 11.
          Show
          dholmes David Holmes added a comment - Is this issue going to be used to remove all the code related to the !UseMembar code paths? i.e. to actually Obsolete UseMembar in JDK 11.
          Hide
          rehn Robbin Ehn added a comment -
          I have not yet gotten feedback from PCC64. I was hoping I would have gotten that for before JDK 10 train leaves jdk/hs.
          But I think we will not get that feedback until PCC64 have TLH [~mdoerr].
          If they need the flag around for another release we need to push the obsoleting to JDK 12.
          So this should _not_ be started since we don't want to end up adding it back.
          Show
          rehn Robbin Ehn added a comment - I have not yet gotten feedback from PCC64. I was hoping I would have gotten that for before JDK 10 train leaves jdk/hs. But I think we will not get that feedback until PCC64 have TLH [~mdoerr]. If they need the flag around for another release we need to push the obsoleting to JDK 12. So this should _not_ be started since we don't want to end up adding it back.
          Hide
          dholmes David Holmes added a comment -
          In that case I suggest adding a sub-task to change the obsolete and expired versions to undefined for now. As soon as we go to JDK 11 the VM will issue an Obsoletion warning and complain that the flag should have been removed. so we need to update the information in the VM. Thanks.
          Show
          dholmes David Holmes added a comment - In that case I suggest adding a sub-task to change the obsolete and expired versions to undefined for now. As soon as we go to JDK 11 the VM will issue an Obsoletion warning and complain that the flag should have been removed. so we need to update the information in the VM. Thanks.
          Hide
          rehn Robbin Ehn added a comment -
          Yes, good suggestion. I asked Martin for feedback so lets give him a day to respond before we commit that change.
          Show
          rehn Robbin Ehn added a comment - Yes, good suggestion. I asked Martin for feedback so lets give him a day to respond before we commit that change.
          Hide
          mdoerr Martin Doerr added a comment - - edited
          Transitioning to native is clearly slower with UseMembar than using the serialization page on PPC64 (in both, single and multi-threaded micro benchmarks). The same applies to single-threaded micro bencharks on multi-socket x86_64 xystems. However, we didn't notice any regressions in large benchmark suites (e.g. SPEC jvm and jbb in different flavours). This was evaluated in JDK-8187809 and UseMembar was switched on on PPC64.
          My assuption is that the optimizations proposed in "JEP 312: Thread-Local Handshakes" which benefit from not using the serialization page will outweigh the performance regression caused by activating UseMembar. But I haven't seen these optimizations, yet. (JEP 312 is available on PPC64 in jdk10.)
          Show
          mdoerr Martin Doerr added a comment - - edited Transitioning to native is clearly slower with UseMembar than using the serialization page on PPC64 (in both, single and multi-threaded micro benchmarks). The same applies to single-threaded micro bencharks on multi-socket x86_64 xystems. However, we didn't notice any regressions in large benchmark suites (e.g. SPEC jvm and jbb in different flavours). This was evaluated in JDK-8187809 and UseMembar was switched on on PPC64. My assuption is that the optimizations proposed in "JEP 312: Thread-Local Handshakes" which benefit from not using the serialization page will outweigh the performance regression caused by activating UseMembar. But I haven't seen these optimizations, yet. (JEP 312 is available on PPC64 in jdk10.)
          Hide
          rehn Robbin Ehn added a comment - - edited
          We do as [~dholmes] suggested and revisit this in JDK 12.
          Show
          rehn Robbin Ehn added a comment - - edited We do as [~dholmes] suggested and revisit this in JDK 12.

            People

            • Assignee:
              rehn Robbin Ehn
              Reporter:
              dholmes David Holmes
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated: