Summary: Use resource memory instead of c-heap for the exception message
Reviewed-by: phh, jmasa

Summary: An assert in the management.cpp is too strong and assumes the max size is always defined on memory pools, even when we don't need to use it.
Reviewed-by: mchung, johnc

Summary: simple correction in testcase
Reviewed-by: mchung

Summary: Disable stack bounds checks in product mode other than for the initial thread
Reviewed-by: coleenp, jcoomes, aph

Reviewed-by: tonyp, ysr

Summary: The way we were caluclating the max value meant that it might fluctuate during the run and this broke some assumptions inside the MBeans framework. This change sets the max value of each pool to -1, which means undefined according to the spec.
Reviewed-by: mchung, johnc

Summary: This is the renaming part of 6961697 to keep the actual changes small for review.
Reviewed-by: kvn, never

Summary: Weakened a too-strong, off-by-one assert; added code to keep track of and report any overflows at appropriate level of verbosity.
Reviewed-by: jcoomes, tonyp

6896381: CTW fails share/vm/ci/bcEscapeAnalyzer.cpp:99, assert(_stack_height < _max_stack,"stack overflow")
Summary: Check constant Tag type instead of calling get_constant().
Reviewed-by: never

Reviewed-by: kvn

Summary: Delete the hs19-b06 Hg tag, as it was put on incorrectly
Reviewed-by: jcoomes

Summary: Change the build number back to 06
Reviewed-by: jcoomes

Summary: Update the HS19 build number to 07
Reviewed-by: jcoomes

Reviewed-by: kvn

Reviewed-by: jcoomes, jmasa, tonyp

6885308: The incorrect -XX:StackRedPages, -XX:StackShadowPages, -XX:StackYellowPages could cause VM crash
Summary: Test minimal stack sizes given (also fixed linux compilation error)
Reviewed-by: never, phh, coleenp

Summary: Allow for the possibility (when the heap is expanding) that the sweep might skip over and past, rather than necessarily step on, the sweep limit determined at the beginning of a concurrent marking cycle.
Reviewed-by: jmasa, tonyp

Summary: The changes introduced for 6975078 assign badHeapOopVal to the _allocation field in the ResourceObj class. In 32 bit linux builds with certain versions of gcc this assignment will be flagged as an error while compiling allocation.cpp. In 32 bit builds the constant value badHeapOopVal (which is cast to an intptr_t) is negative. The _allocation field is typed as an unsigned intptr_t and gcc catches this as an error.
Reviewed-by: jcoomes, ysr, phh

Summary: A number of fixes for Zero and Shark.
Reviewed-by: twisti
Contributed-by: NGary Benson <gbenson@redhat.com>

Reviewed-by: wrockett

6975964: G1: print out a more descriptive message for evacuation failure when +PrintGCDetails is set
Summary: we're renaming "evacuation failure" to "to-space overflow". I'm also piggy-backing a small additional change which removes the "Mark closure took..." output.
Reviewed-by: ysr, johnc

Summary: as the title says, sometimes we are allocating humongous objects in young regions and we shouldn't.
Reviewed-by: ysr, johnc

Summary: There are a few issues in the code that calculates whether to resize the heap and by how much: a) some calculations can overflow 32-bit size_t's, b) min_desired_capacity is not bounded by the max heap size, and c) the assrt that fires is in the wrong place. The fix also includes some tidying up of the related verbose code.
Reviewed-by: ysr, jmasa