-
Enhancement
-
Resolution: Fixed
-
P4
-
11
This again and again causes us to add an additional abstraction layer above any code that tries to use parallel threads for all collectors (evacuation failure, dynamic thread sizing, reference processing, ...).
Further the parallel gc task queue mechanism has disadvantages:
- the work (tasks) must be known beforehand
- getting work from the task queue incurs taking a global lock which is actually known for being inefficient in literature already
Investigate to replace the parallel gc task queue mechanism with a work gang.
proposed solution:
- blocks
-
JDK-8210100 ParallelGC should use parallel WeakProcessor
-
- Resolved
-
- relates to
-
JDK-8224660 Parallel GC: Use WorkGang (2: MarksFromRootsTask)
-
- Resolved
-
-
JDK-8224661 Parallel GC: Use WorkGang (3: UpdateDensePrefixAndCompactionTask)
-
- Resolved
-
-
JDK-8224662 Parallel GC: Use WorkGang (4: SharedRestorePreservedMarksTaskExecutor)
-
- Resolved
-
-
JDK-8224663 Parallel GC: Use WorkGang (5: ScavengeRootsTask)
-
- Resolved
-
-
JDK-8224664 Parallel GC: Use WorkGang (6: PSRefProcTaskProxy)
-
- Resolved
-
-
JDK-8224665 Parallel GC: Use WorkGang (7: remove task manager)
-
- Resolved
-
-
JDK-8224666 Parallel GC: Use WorkGang (8: obsolete and remove flags)
-
- Resolved
-
-
JDK-8231670 Remove TaskExecutor abstraction used in preserved marks processing
-
- Resolved
-
-
JDK-8231672 Simplify the reference processing parallelization framework
-
- Resolved
-
-
JDK-4996670 RFE: ParallelScavenge needs NoResourceMarkVerifier guards
-
- Closed
-
-
JDK-8231669 Remove WorkerManager abstraction to support multiple work gang implementations
-
- Closed
-
-
JDK-8267214 assert(cm->region_stack()->is_empty()) failed: Region stack 0 is not empty
-
- Closed
-
-
JDK-8204686 Dynamic parallel reference processing support for Parallel GC
-
- Resolved
-
-
JDK-8224659 Parallel GC: Use WorkGang (1: PCRefProcTask)
-
- Resolved
-