RFR: 8253237: [REDO] Improve large object handling during evacuation

[Albert Mingkun Yang]

On Sat, 19 Sep 2020 17:03:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to improve the handling of arrays by G1's
> copy_to_survivor_space.
> 
> This is essentially the same change that was pushed 9/15:
> https://bugs.openjdk.java.net/browse/JDK-8158045
> https://github.com/openjdk/jdk/pull/90
> 
> and then backed out due to tripping over a compiler bug:
> https://bugs.openjdk.java.net/browse/JDK-8253169
> [BACKOUT] Improve large object handling during evacuation
> https://github.com/openjdk/jdk/pull/181
> 
> That compiler bug has been worked around:
> https://bugs.openjdk.java.net/browse/JDK-8253270
> Limit fastdebug inlining in G1 evacuation
> https://github.com/openjdk/jdk/pull/220
> 
> so now redoing the original change to array handling.  The original
> JDK-8158045 change was cherry-picked into this change.  There were a couple of
> minor merge conflicts with JDK-8253270.
> 
> The actual change (substantially cribbed from the old PR):
> 
> Change 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 several 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, possibly enqueuing multiple partial array tasks
> for an array that is large enough.  Initially no more than one partial array
> task will be enqueued.  As each such tasks is processed, an increasing number
> of additional tasks may be enqueued, up to a limit based on the number of
> worker threads.  This gives other threads an opportunity to steal such tasks,
> while keeping queue growth under control.  Most of the calculation for this is
> handled by a new helper class, so this can later be shared with ParallelGC.
> This addresses JDK-8158045.
> 
> The dispatch on array klass type has also been changed. It will now break (via
> an assert) Project Valhalla, rather than quietly doing something that probably
> isn't what is actually wanted. I've discussed this with them so there is a
> plan for dealing with it when they take this update.
> 
> Deleted a lingering reference to G1ParScanPartialArrayClosure that was deleted
> long ago (JDK-8035330, JDK 9).
> 
> Ran tier1-6 in mach5 and some local stress tests.
> 
> I've not redone performance testing.  I don't think there should be any change
> from the previous go-round, which was pretty much performance neutral.

Marked as reviewed by ayang (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/266