-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b14
This method is the allocation entry API for mutators. Its flow is the following
1. try young-gen
2. try old-gen
3. invoke GC operation
4. if GC-op succeeds, return; otherwise, go to 1
Before step 3, we need to call `total_collections()`, which requires holding `Heap_lock`. The current code invokes old-gen allocation while holding `Heap_lock`.
However, the old-gen allocation API supports multi-thread, so it can be moved outside the critical-region. This cleans up the structure and streamlines the flow.
1. try young-gen
2. try old-gen
3. invoke GC operation
4. if GC-op succeeds, return; otherwise, go to 1
Before step 3, we need to call `total_collections()`, which requires holding `Heap_lock`. The current code invokes old-gen allocation while holding `Heap_lock`.
However, the old-gen allocation API supports multi-thread, so it can be moved outside the critical-region. This cleans up the structure and streamlines the flow.
- causes
-
JDK-8367665 Regressions in SPECjbb2005-ParGC (~6%) and SPECjvm2008-SOR.large-ParGC (~1-5%) on Linux x64/AArch64 from JDK-8365557 and/or JDK-8366063
-
- Closed
-
- relates to
-
JDK-8367737 Parallel: Retry allocation after lock acquire in mem_allocate_work
-
- Resolved
-
- links to
-
Commit(master) openjdk/jdk/1feb9bd5
-
Review(master) openjdk/jdk/26779