RFR(XS): 8025644 java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java fails with TestData$OfRef): failure java.lang.AssertionError: expected [true] but found [false]

[Vladimir Kozlov]

Igor,

Please, add this explanation to the bug report.
You said before that a dynamic check was missed and I mistakenly thought 
it was check in maybe_cast_profiled_receiver() but it was in 
array_store_check(). Now it makes sense. Changes are good.

Please, also run CTW tests.

Note: our repo hs-comp is closed only for ppc-aix fixes. Please, hold on 
your push.

Thanks,
Vladimir

On 1/30/14 1:42 AM, Igor Veresov wrote:
>
> On Jan 29, 2014, at 11:35 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> Igor,
>>
>> I need more explanation. I don't see how exactness of object type affects generation of type check in maybe_cast_profiled_receiver().
>
> It’s the exactness of the array element klass type.
>
> Here is the normal scenario:
> In Parse::array_store_check() we speculatively assume the klass of the array (see the check and the UCT we emit there). If we pass the check the type of the array is exact and hence the type of klass the array element is exact. We pass that klass of the element as the superklass to gen_checkcast(). The maybe_cast_profiled_receiver() kicks in and tries to statically cast the speculative type of the object that we want to store into the array to the superklass, if it can do that (SSC_always_true) the only other thing we need to check is that the type of the object is indeed the type we expect (another check and UCT). If we cannot do the static cast, maybe_cast_profiled_receiver() returns null and we emit a full blown check.
>
> Now the bad scenario:
> We deopted too much in the array klass check we emitted in Parse::array_store_check(). So when we recompile we skip the opportunity to assert the exactness of the klass of the array (too_many_traps(Deoptimization::Reason_array_check) == true), and just load the element type klass from the inexact array klass. The element klass type would be j.l.Object and not exact (we cannot really know in this case until we load). We go into gen_checkcast() and into maybe_cast_profiled_receiver() assuming this element klass is  the superklass. And we happily rely of the non-exact type to statically cast our speculative type of the stores object to j.l.Object. Which is wrong. The whole thing only works if the superklass is the true exact superklass.
>
> So, the fix is not to do the second part of the speculation if we don’t really know the exact type of the element, which is really a requirement for it all to work.
> Instead we just emit the full check…
>
> Does it make sense?
>
> igor
>
>
>> Is it because it returns NULL since static_subtype_check() does not return SSC_always_true and type_check_receiver() is not generated? type_check_receiver() generates dynamic check of klass from profiling vs klass loaded from object's header, it can't collapse.
>>
>> Thanks,
>> Vladimir
>>
>> On 1/29/14 10:35 PM, Igor Veresov wrote:
>>> When we parse an aastore one of the optimizations we try is to statically cast the speculative type of the object that we obtained during profiling to the type of the superklass (which is the type of the array element) and then do a dynamic check that the type of the object is exactly what we expect. To work correctly the type of superklass must be exact. The following change adds this check.
>>>
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8025644/webrev.00/
>>> Testing: jtreg, jprt, the failing regression test
>>>
>>> Thanks,
>>> igor
>>>
>