JDK-8159429 : Contention on FreeList_lock during allocating GC regions
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-06-14
  • Updated: 2023-10-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8227174 - Lazily set card table of allocated regions to correct values in G1
Relates :  
JDK-8131668 - Contention on allocating new TLABs constrains throughput on G1
Description
Running some micro benchmarks with lock tracing in the Oracle Studio analyzer show a significant amount of time spent in stack traces (i.e. actual cpu time plus much sync wait time) with G1Allocator::par_allocate_during_gc() holding a lock. This amounts to around 5-10% of evacuation, and almost all sync wait time.

This is most likely the FreeList_lock grabbed before the call to G1AllocRegion::attempt_allocation_locked().

Investigate, and try to improve.
Comments
Explaining the image: par_alloc_during_gc takes 1.229s cpu time, 3.198s sync wait time (ie. waiting for the lock. Total cpu time for G1ParEvacuateFollowersClosure::do_void() is 46.55s (and total wait time 3.198s). Total time is ~50s, of which 3.198s are spent in waiting for that lock, which amounts to ~6.3%. Before taking locks, some amount of cpu time is spent in the active wait loop, increasing that figure a bit.
14-06-2016