JDK-8143878 : Memory serialization page can become a bottleneck
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2015-11-24
  • Updated: 2019-05-28
  • Resolved: 2018-11-09
Related Reports
Relates :  
JDK-8152292 - Consider using proper OS APIs for os::serialize_thread_states
Relates :  
JDK-8213436 - Obsolete UseMembar
Relates :  
JDK-8187809 - UseMembar should be set true and deprecate the flag
Sub Tasks
JDK-8193514 :  
UseMembar should not be obsoleted yet - Resolved
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.
Comments
UseMembar is obsoleted, no longer possible to use anything other than fence.
09-11-2018
We do as [~dholmes] suggested and revisit this in JDK 12.
14-12-2017
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.)
14-12-2017
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.
14-12-2017
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.
14-12-2017
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.
14-12-2017
Yes, good suggestion. I asked Martin for feedback so lets give him a day to respond before we commit that change.
14-12-2017
Deferring to 11 at this time.
06-04-2017