Reviewed-by: kvn, twisti

Reviewed-by: kvn, jrose, dsamersoff

Reviewed-by: kvn, iveresov

Summary: Ifop optimization for c1
Reviewed-by: never, phh, iveresov

Summary: fixes sparc only assert failure following 6972540
Reviewed-by: never

Reviewed-by: never, jrose

Summary: Fix compare-and-swap intrinsic problem with G1 post-barriers and issue with branch ranges in G1 stubs on sparc
Reviewed-by: never, kvn

Reviewed-by: iveresov, tonyp

Summary: Remove G1RemSet base class and StupidG1RemSet class; rename HRInto_G1RemSet to just G1RemSet.
Reviewed-by: ysr, tonyp

Summary: Apply PrintJvmWarnings flag to all warnings
Reviewed-by: coleenp, phh

Reviewed-by: kvn

Reviewed-by: kvn, jrose

Reviewed-by: twisti
Contributed-by: NGary Benson <gbenson@redhat.com>

Reviewed-by: kvn

Reviewed-by: vladidan, dholmes

Summary: min_stack_allowed is a compile time constant and Stack*Pages are settable
Reviewed-by: dholmes, kvn

Reviewed-by: kvn, iveresov, jcoomes

Reviewed-by: iveresov, kvn, kamg

Summary: Set upper limit 256 for ObjectAlignmentInBytes value.
Reviewed-by: never, iveresov

Summary: Fix ciMethod::instructions_size() to return correct value
Reviewed-by: kvn, twisti

Reviewed-by: twisti, kvn, iveresov

Summary: Absolute time 0 needs to return immediately.
Reviewed-by: phh, dcubed, dholmes

Summary: 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

Summary: Clear the concurrent marking "in progress" flag while the FullGCCount_lock is held. This avoids a race that can cause back to back System.gc() calls, when ExplicitGCInvokesConcurrent is enabled, to fail to initiate a marking cycle causing the requesting thread to hang.
Reviewed-by: tonyp, ysr