Added tag hs22-b06 for changeset 9de632dc424b

7091255: Bump the hs22 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo@oracle.com

7091294: disable quicksort tests Reviewed-by: jmasa, ysr, kvn

Merge

Merge

7090654: nightly failures after 7086585 Reviewed-by: kvn

7077806: ARM: java.lang.InternalError: bound subword value does not fit into the subword type Summary: shared fix necessary for ARM/PPC Reviewed-by: twisti, roland

7057978: improve robustness of c1 ARM back-end wrt non encodable constants Summary: ARM only, avoid assertion failures for huge constants generated by C1 shared code Reviewed-by: never, vladidan

7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp Summary: Replace assert with check to delete MachTemp nodes only when they are really dead. Reviewed-by: never

7089709: type "jushort" not found Reviewed-by: kvn, twisti

7088955: add C2 IR support to the SA Reviewed-by: kvn

7086585: make Java field injection more flexible Reviewed-by: jrose, twisti, kvn, coleenp

7088020: SEGV in JNIHandleBlock::release_block Reviewed-by: kvn, twisti

7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 Summary: Revert changes which caused regression. Reviewed-by: never

Merge

7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs Summary: PhaseChaitin::yank_if_dead() should be able to handle MachTemp inputs as a special case and yank them. Reviewed-by: never, kvn

7087947: Add regression test for 7068051 Summary: Add regression test. Reviewed-by: never

7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never

7087445: Improve platform independence of JSR292 shared code Summary: changes necessary for some JSR292 ports Reviewed-by: jrose, dholmes

7054211: No loop unrolling done in jdk7b144 for a test update() while loop Summary: restore unrolling code for CaffeineMark. Reviewed-by: never

7090259: Fix hotspot sources to build with old compilers Summary: Fixed warnings which prevent building VM with old compilers. Reviewed-by: never

7090069: Java launcher hangs in infinite loop on windows when UseNUMA[Interleaving] is specified Summary: Fix _numa_used_node_list array size specification Reviewed-by: kvn, johnc, jmasa, ysr

7089625: G1: policy for how many old regions to add to the CSet (when young gen is fixed) is broken Summary: When refactoring the code for a previous fix, a condition was not correctly negated which prevents the G1 policy from adding the correct number of old regions to the CSet when the young gen size is fixed. The changeset also fixes a small syntactical issue in g1ErgoVerbose.hpp which is causing compiler warnings. Reviewed-by: brutisso, ysr

Added tag hs22-b05 for changeset 2787676b53cf

7088991: Bump ths hs22 build number to 05 Reviewed-by: johnc Contributed-by: alejandro.murillo@oracle.com

Merge

Merge

7087717: G1: make the G1PrintRegionLivenessInfo parameter diagnostic Reviewed-by: brutisso, ysr

6929868: G1: introduce min / max young gen size bounds Summary: Make G1 handle young gen size command line flags more consistently Reviewed-by: tonyp, jwilhelm

7084509: G1: fix inconsistencies and mistakes in the young list target length calculations Summary: Fixed inconsistencies and mistakes in the young list target length calculations so that a) the calculated target length is optimal (before, it was not), b) other parameters like max survivor size and max gc locker eden expansion are always consistent with the calculated target length (before, they were not always), and c) the resulting target length was always bound by desired min and max values (before, it was not). Reviewed-by: brutisso, johnc

7086226: UseNUMA fails on old versions of windows Summary: Return correct answers from os::numa_*() for UMA machines or if NUMA API is not supported Reviewed-by: johnc

4965777: GC changes to support use of discovered field for pending references Summary: If and when the reference handler thread is able to use the discovered field to link reference objects in its pending list, so will GC. In that case, GC will scan through this field once a reference object has been placed on the pending list, but not scan that field before that stage, as the field is used by the concurrent GC thread to link discovered objects. When ReferenceHandleR thread does not use the discovered field for the purpose of linking the elements in the pending list, as would be the case in older JDKs, the JVM will fall back to the old behaviour of using the next field for that purpose. Reviewed-by: jcoomes, mchung, stefank