Summary: The free list is being maintained in a sorted fashion and old and humongous regions are allocated from the bottom of the heap while young regions are allocated at the top.
Reviewed-by: tschatzl, mgerdin
Contributed-by: jesper.wilhelmsson@oracle.com, staffan.friberg@oracle.com

Summary: Pad and cache-align BiasedMappedArray instances by default to avoid performance variability problems due to false sharing, as instances of this data structures are typically used for performance sensitive code.
Reviewed-by: brutisso, stefank

Summary: Mentioned closures are actually wrapped methods. This adds confusion to readers, and in this case also increases code size as G1ParScanHeapEvacClosure is part of the oop_oop_iterate() methods. Move them into G1ParScanThreadState as methods.
Reviewed-by: stefank

Summary: Refactor the From Card Cache into a separate class.
Reviewed-by: jmasa

Summary: Detailed breakdown of time spent in the evacuation failure handling phases to make the "Other" time roughly correspond to the sum of its parts.
Reviewed-by: jwilhelm, jmasa

Summary: Show the time taken by card redirtying during GC in a new "Redirty Cards" line.
Reviewed-by: jwilhelm, brutisso

Summary: Improve fast card cache iteration and avoid taking locks when freeing the collection set.
Reviewed-by: brutisso

Summary: The from card cache is a very frequently accessed data structure. It is essentially a 2d array of per-region values, one row of values for every GC thread. Pad and align the data structure to avoid false sharing.
Reviewed-by: stefank

Summary: Change the code cache remembered sets data structure from a GrowableArray to a chunked list of nmethods. This makes the data structure more amenable to parallelization, and decreases freeing time.
Reviewed-by: mgerdin, brutisso

Reviewed-by: brutisso, tschatzl

Reviewed-by: brutisso, tschatzl

Reviewed-by: tschatzl, pliden

Reviewed-by: tschatzl, pliden

Reviewed-by: mgerdin, jmasa
Contributed-by: matthias.baesken@sap.com

Summary: Revert JDK-6976350 because it does not improve PLAB fragmentation. To the contrary, it tends to increase the amount of wasted space with many threads.
Reviewed-by: brutisso

Summary: Move G1ParCopyClosure::copy_to_survivor_space to decrease code size.
Reviewed-by: stefank, jmasa

Summary: Remove the assumption that G1CollectedHeap::in_cset_fast_test needs to check for NULL references. Most of the time this is not required, making the code doing this check multiple times.
Reviewed-by: stefank, mgerdin, jmasa

Summary: Move methods that are not dependent on any of G1ParCopyClosure's template parameters into G1ParCopyHelper. Further remove unused methods and members of the class hierarchy.
Reviewed-by: mgerdin, stefank

Reviewed-by: tonyp, tschatzl

Summary: When string and symbol table unlink are not performed in parallel, the claim index we check is not updated, and so a guarantee fails. Take this into account when checking the guarantee.
Reviewed-by: brutisso, jwilhelm

8033106: Wrong predicate for checking whether the correct amount of symbol table entries have been processed in G1
Summary: The change fixes the predicate check.
Reviewed-by: jmasa, tonyp, stefank

Summary: Clean up and slightly optimize reference handling from the GC reference task queue. Since we never push partial array chunks as narrowOop* we can manually specialize the code so that some code can be optimized away.
Reviewed-by: tonyp, brutisso, stefank

Summary: Made the flags Min- and MaxHeapFreeRatio manageable, and implemented support for these flags in ParallelGC.
Reviewed-by: sla, mgerdin, brutisso

Reviewed-by: tschatzl, stefank, jmasa

8020277: Young GC could be extremely slow due to assertion in ObjectStartArray::object_starts_in_range
8009462: Young GC's (ParNewGC and SerialGC) have unexpected variances.
Summary: Removed the assertion slowing down GC.
Reviewed-by: stefank, mgerdin

Summary: Remove the above mentioned template parameter and related unused code. Also remove some classes that are never used.
Reviewed-by: stefank, mgerdin, jwilhelm

8027454: Do not traverse string table during G1 remark when treating them as strong roots during initial mark
Summary: Do not try to unlink string table entries unconditionally during remark. This is without side effects as the preceding initial mark always uses the string table as strong roots. Needs to be fixed with class unloading during concurrent mark.
Reviewed-by: brutisso, mgerdin

8027455: Improve symbol table scan times during gc pauses
Summary: Parallelize string table and symbol table scan during remark and full GC. Some additional statistics output if the experimental flag G1TraceStringSymbolTableScrubbing is set.
Reviewed-by: mgerdin, coleenp, brutisso

Reviewed-by: brutisso, mgerdin, tschatzl

Summary: Correct timing measurement by modifying the scope of the GCTraceTime instance.
Reviewed-by: ysr, tamao
Contributed-by: NJeremy Manson <jeremymanson@google.com>

Summary: Copyright year updated for files modified during 2013
Reviewed-by: twisti, iveresov

Summary: Reducing the number of calls to follow_class_loader to speed up the marking phase. Also removed some unnecessary calls to adjust_klass.
Reviewed-by: stefank, jmasa, mgerdin

Reviewed-by: brutisso, jmasa, jwilhelm

Summary: Reduced the number of calls to follow_class_loader and instead marked and pushed the klass holder directly. Also removed unneeded calls to adjust_klass.
Reviewed-by: coleenp, jmasa, mgerdin, tschatzl

Reviewed-by: dholmes, egahlin

Summary: Needed to update _space_alignment in generation sizer to ensure correct sizing of spaces.
Reviewed-by: jmasa, tschatzl

Reviewed-by: brutisso, tschatzl, mgerdin

Summary: Change checks for isHumongous() to continuesHumongous() as installing a code root for a humongous object is valid, but not for continuations of humongous objects. Cleaned up asserts.
Reviewed-by: jmasa, tamao

7057939: jmap shows MaxNewSize=4GB when Java is using parallel collector
Summary: Major cleanup of the collectorpolicy classes
Reviewed-by: tschatzl, jcoomes

Summary: The field G1AllocRegion::_alloc_region needs to be declared volatile as it is used with that intention. Otherwise the compiler may generate the code that reloads the value which might have changed in the meantime, leading to spurious crashes.
Reviewed-by: iveresov, simonis, tschatzl
Contributed-by: NAxel Siebenborn <axel.siebenborn@sap.com>