RFR: 8158045: Improve large object handling during evacuation

[Kim Barrett]

> On Aug 27, 2020, at 12:42 PM, Albert Yang <albert.m.yang at oracle.com> wrote:
> 
> Hi,
> 
> Sorry, I accidentally pressed "send" before finishing my review ...
> 
> ```
> 499     if (klass->is_array_klass()) {
> 500       if (klass->is_typeArray_klass()) {
> 501         // Nothing needs to be done for typeArrays.  Body doesn't contain
> 502         // any oops to scan, and the type in the klass will already be handled
> 503         // by processing the built-in module.
> 504         return obj;
> 505       } else if (klass->is_objArray_klass()) {
> 506         // Do special handling for objArray.
> 507         return start_partial_objArray(dest_attr, old, obj);
> 508       }
> 509       // Not a special array, so fall through to generic handling.
> 510     }
> ```
> 
> I thought an array can only be typeArray or objArray. What is the third case?

Project Valhalla.  See JDK-8252330.  I didn't want to cause them any
problems when merging this change into their repository, so no assumptions
or assertions about there being only typeArray and objArray.  They'll just
have the same unsplit inlined type arrays as before, and now there's an RFE
to track that.

> Since each if branch contains a `return`, putting each if-condition in a separate line could make each case more distinguishable.
> 
> ```
> if (klass->is_typeArray_klass()) {
>  return ...;
> }
> 
> if (klass->is_objArray_klass()) {
>  return ...;
> }
> ```

I prefer the if-ladder style for something like this. And if it weren't for
the current need for fall through I'd probably put a single common return at
the end of the array handling cases.