[9] RFR (XS): 8058825: EA: ConnectionGraph::split_unique_types does incorrect scalar replacement

[Vladimir Ivanov]

Thanks, Vladimir.

I haven't looked into what is the difference between these 2 
implementations. The failing test case requires very special IR shape, 
so it's very easy to break it even on 8u40.

What I saw on 9 is that there are no eliminated allocations on the test. 
I experimented a little [1] with the test case and it seems the new 
shape doesn't allow both allocations to go away. Both allocations go 
away on 8u40 and there's no allocation elimination on 9.

I'll investigate what's going on there and file a followup bug if 
necessary.

Best regards,
Vladimir Ivanov

[1]
// $ java -XX:-TieredCompilation -XX:CompileOnly=ArraysCopyOf.test 
-XX:+PrintCompilation -XX:+PrintInlining -XX:+PrintAnalysis 
-XX:+PrintEliminateAllocations -XX:+TraceDeoptimization ArraysCopyOf
public class ArraysCopyOf {
     volatile static int count = 0;
     public static void main(String[] args) throws Throwable {
         while (true) {
             count += test(String[].class);
         }
     }
     static int test(Class<?> arrayType) {
         Class<? extends Object[]> objArrayType = 
arrayType.asSubclass(Object[].class);

         Object[] example = java.util.Arrays.copyOf(new Object[] {}, 0, 
objArrayType);

         return example.length;
     }
}


On 9/29/14, 8:32 PM, Vladimir Kozlov wrote:
> Looks good. But can you explain what is changed in Arrays::copyOf in
> jdk9 and how it affected this problem?
> Did the allocation became escaped?
>
> Thanks,
> Vladimir K
>
> On 9/29/14 9:16 AM, Vladimir Ivanov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8058825
>> http://cr.openjdk.java.net/~vlivanov/8058825/webrev.00/
>>
>> In some cases an allocation of non-escaping object can be eliminated,
>> but there's no precise type information to
>> rematerialize it. In that case, if there's a need to rematerialize the
>> object, an object of possibly wrong type will be
>> instantiated.
>>
>> The fix is to avoid allocation elimination, if the type isn't precise.
>> The downside is that allocation isn't eliminated
>> even if object rematerialization support isn't required. Filed
>> JDK-8059378 [1] to track EA enhancement for this
>> particular case.
>>
>> The bug was found in 8u40 with an old implementation of Arrays::copyOf
>> intrinsic. The intrinsic implementation has been
>> updated in 9.
>> I wasn't able to come up with a regression test, which can reliably
>> reproduce the problem in 9.
>>
>> Testing: tested w/ regression test (attached to the bug) on 8u40.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8059378