Acquire the pending list lock in the prologue method of G1's concurrent VM_Operation and release the lock in the epilogue() method. The locking/unlocking order of the pending list lock and the Heap_lock should match that in the prologue and epilogue methods of VM_GC_Operation.
Reviewed-by: tonyp, ysr
Integrate bsd-port/hotspot and macosx-port/hotspot changes as of 2011.09.29.
Co-authored-by: Greg Lewis <glewis@eyesbeyond.com>
Co-authored-by: Kurt Miller <kurt@intricatesoftware.com>
Co-authored-by: Alexander Strange <astrange@apple.com>
Co-authored-by: Mike Swingler <swingler@apple.com>
Co-authored-by: Roger Hoover <rhoover@apple.com>
Co-authored-by: Victor Hernandez <vhernandez@apple.com>
Co-authored-by: Pratik Solanki <psolanki@apple.com>
Reviewed-by: kvn, dholmes, never, phh
Co-authored-by: Greg Lewis <glewis@eyesbeyond.com>
Co-authored-by: Jung-uk Kim <jkim@freebsd.org>
Co-authored-by: Christos Zoulas <christos@zoulas.com>
Co-authored-by: Landon Fuller <landonf@plausible.coop>
Co-authored-by: The FreeBSD Foundation <board@freebsdfoundation.org>
Co-authored-by: Michael Franz <mvfranz@gmail.com>
Co-authored-by: Roger Hoover <rhoover@apple.com>
Co-authored-by: Alexander Strange <astrange@apple.com>
Reviewed-by: kvn, twisti, jrose
Removed the unused clear argument to various cardtbale methods and unused mod_oop_in_space_iterate method. Unrelated to synopsis, added a pair of clarifying parens in AllocationStats constructor.
Reviewed-by: brutisso, jcoomes
Under certain circumstances a safepoint could happen between a JavaThread object being created and that object being added to the Java threads list. This could cause the active field of that thread's SATB queue to get out-of-sync with respect to the other Java threads. The solution is to activate the SATB queue, when necessary, before adding the thread to the Java threads list, not when the JavaThread object is created. The changeset also includes a small fix to rename the surrogate locker thread from "Surrogate Locker Thread (CMS)" to "Surrogate Locker Thread (Concurrent GC)" since it's also used in G1.
Reviewed-by: iveresov, ysr, johnc, jcoomes
G1 was not handling explicit GCs correctly in many ways. It does now. See the CR for the list of improvements contained in this changeset.
Reviewed-by: iveresov, ysr, johnc
Autonomic per-worker free block cache sizing, tunable coalition policies, fixes to per-size block statistics, retuned gain and bandwidth of some feedback loop filters to allow quicker reactivity to abrupt changes in ambient demand, and other heuristics to reduce fragmentation of the CMS old gen. Also tightened some assertions, including those related to locking.
Reviewed-by: jmasa
Treat ProfileData in MDO's as a source of weak, not strong, roots. Fixes the bug for stop-world collection -- the case of concurrent collection will be fixed separately.
Reviewed-by: jcoomes, jmasa, kvn, never
Removing the concurrent overhead tracker from G1, along with the GC overhead reporter and the G1AccountConcurrentOverhead (both of which rely on the the concurrent overhead tracker).
Reviewed-by: iveresov, johnc
Call newly created CollectedHeap::dump_{pre,post}_full_gc before and after every stop-world full collection cycle on GenCollectedHeap and ParallelScavengeHeap. (Support for G1CollectedHeap forthcoming under CR 6810861.) Small modifications to existing heap dumping and class histogram implementation, especially to allow multiple on-the-fly histos/dumps by the VM thread during a single safepoint.
Reviewed-by: jmasa, alanb, mchung
