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

[Kim Barrett]

On Mon, 21 Sep 2020 18:26:13 GMT, Thomas Schatzl <tschatzl 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 tschatzl (Reviewer).

Thanks for reviews, Stefan, Albert, and Thomas.

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

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