RFR: 8158045: Improve large object handling during evacuation

[Kim Barrett]

RFR: 8158045: Improve large object handling during evacuation
RFR: 8027761: Investigate fast-path for scanning only objects with references during gc
RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space

Please review this change to type dispatching and handling in G1's
evacuation copying, in order to improve the hot paths and improve array
handling. This change addresses several closely co-located enhancement
requests; it seemed difficult to split them up in a sensible way.

do_copy_to_survivor_space now gets the klass of the object being copied
once, up front, for use in multiple places. This avoids fetching (including
re-decoding when compressed) the klass multiple times. This addresses part
of JDK-8027545.

Moved check for and handling of string deduplication later, only applying it
after the special array cases have been dealt with, since strings are not
arrays.  (They are header objects pointing to an array of character values.)

Special case typeArray, doing nothing other than the copy, since they
contain no oops that need to be processed.  This addresses JDK-8027761.

Changed handling of objArray, pushing all of the partial array tasks up
front, rather than processing the current chunk after pushing a single task
for the remaining work.  This addresses JDK-8158045.

As part of these, cached some more frequently accessed values in
G1ParScanThreadState member variables. This addresses part of part of
JDK-8027545.

While both the old and new code will work for Project Valhalla, the handling
of arrays should be updated for that project, which introduces new array
types.

Deleted a lingering reference to G1ParScanPartialArrayClosure that was
deleted long ago (JDK-8035330, JDK 9).

CR:
https://bugs.openjdk.java.net/browse/JDK-8158045
https://bugs.openjdk.java.net/browse/JDK-8027761
https://bugs.openjdk.java.net/browse/JDK-8027545

Webrev:
https://cr.openjdk.java.net/~kbarrett/8158045/open.00/

Testing:
tier1-3

performance testing - seems to be at worst performance neutral, with a
statistically significant 3% improvement in specjbb2015 critical-jops seen
on one platform.