Loading...

XML

Word

Printable

Sometimes humongous allocations could trigger excessive concurrent mark cycles, although young-gen collections already reclaim many humongous objects with eager reclamation.
G1 could abort such unnecessary concurrent mark cycles in such cases.

See discussions in:
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-January/028357.html
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-March/028712.html

blocks

JDK-8248783 G1: Trigger concurrent start if humongous allocation needs the reserved space to avoid evac failure

is blocked by

JDK-8253177 outputStream not declared in markWord.hpp

JDK-8248221 G1: millis_since_last_gc updated at wrong time

JDK-8247928 Refactor G1ConcurrentMarkThread for mark abort

relates to

JDK-8248917 G1: Reconsider counting aborted concurrent marks as full collections

JDK-8316355 G1: Improve concurrent undo cycle to be more efficient

JDK-8242847 G1 should not clear mark bitmaps with no marks

JDK-8253928 G1: Remove G1ConcurrentMarkThread::set_in_progress declaration

JDK-8265326 Strange Characters in G1GC GC Log

JDK-8253902 G1: Starting a new marking cycle before the conc mark thread fully completed causes assertion failure

JDK-8245511 G1 adaptive IHOP does not account for reclamation of humongous objects by young GC

links to

Commit openjdk/jdk/37b70282

Review openjdk/jdk/177

(6 relates to, 2 links to)