RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v56]

[Xiaolong Peng]

To protect against unauthorized use of the Oracle email brand, we will be implementing a strict DMARC policy as part of our email security. DMARC (Domain-based Message Authentication, Reporting and Conformance) will help protect against phishing attacks, spam campaigns, and other malicious activities. 

With this implementation, emails sent on behalf of ANY Oracle owned domain will be restricted if they fail DMARC compliance. 

DMARC Info : 
Record= v=DMARC1;p=none;rua=mailto:dmarc_rua at emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf at emaildefense.proofpoint.com;fo=1
Result= none

Questions and more information:

* You may need to take action if you're responsible for email flow from Oracle Cloud, OCI, or acquisition domains. Senders in this category are treated as external emails since they operate outside of Oracle's internal network.

* If you are using the OCI Email Delivery Service, ensure you generate DKIM for your related Header From Domain - refer to https://docs.oracle.com/en-us/iaas/Content/Email/Tasks/configuredkim.htm more info can be found here https://confluence.oraclecorp.com/confluence/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions

* Refer to the DMARC FAQ https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ to learn more about DMARC, if your emails may be affected, and actions you need to take.

* If you have questions, reach out to the #oracle-owned-domains-dmarc Slack channel.

Thank you in advance for your attention to this matter.

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code:
> 
> * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class.
> * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and  `_yield_to_safepoint` to customize the allocator for mutator.
> * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. 
> * ShenandoahOldCollectorAllocator:  allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector`
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. 
> 
> java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> 
> 
> Openjdk TIP:
> 
> ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 2...

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  FullGC should not update accounting when release alloc regions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26171/files
  - new: https://git.openjdk.org/jdk/pull/26171/files/f47d086a..64ac804d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=54-55

  Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

PR: https://git.openjdk.org/jdk/pull/26171