-
Bug
-
Resolution: Fixed
-
P2
-
9
-
b116
-
Not verified
This data structure can get really huge (80G+ @ 3T heap with 800 threads), so it takes a long time to process that data structure by a single thread.
Even startup is delayed by ~15mins by that on such machines
- blocks
-
JDK-8151386 Extract card live data out of G1ConcurrentMark
-
- Resolved
-
- duplicates
-
JDK-8151482 G1 uses too much physical memory for BitMap during JVM start-up
-
- Closed
-
-
JDK-8143024 Make aggregate-data phase concurrent
-
- Closed
-
-
JDK-8151517 Investigate moving the aggregate count data phase into concurrent
-
- Closed
-
- relates to
-
JDK-8178105 Switch mark bitmaps during Remark
-
- Resolved
-
-
JDK-8151069 Parallelize clearing the per-thread concurrent mark data structures
-
- Closed
-
-
JDK-8151215 Modify layout of (large) Concurrent Mark data structures
-
- Closed
-
-
JDK-8152932 Investigate optimal method to set bits in card live data
-
- Closed
-
-
JDK-8153843 G1CardLiveDataHelper incorrectly sets next_live_bytes on dead humongous regions
-
- Resolved
-
-
JDK-8155917 Memory access in free regions during G1 full gc causes regressions in SPECjvm2008 scimark.fft,lu,sor,sparse with 9+116 on Linux-x64
-
- Closed
-
-
JDK-8151814 Tune thread usage for concurrent tasks
-
- Open
-
-
JDK-8017163 G1: Refactor remembered sets
-
- Resolved
-