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

[Vladimir Kozlov]

On 9/29/14 11:30 AM, Vladimir Ivanov wrote:
> 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.

Yes, please file a new bug if we indeed reduced EA opportunities in jdk9.

Thanks,
Vladimir K

>
> 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