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] (original) (raw)

Igor Veresov igor.veresov at oracle.com
Sat Feb 1 20:28:41 PST 2014

On Jan 30, 2014, at 10:22 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

Igor,

Please, add this explanation to the bug report.

Done!

You said before that a dynamic check was missed and I mistakenly thought it was check in maybecastprofiledreceiver() but it was in arraystorecheck(). Now it makes sense. Changes are good.

Thanks for the review!

Please, also run CTW tests.

Done, all clear.

igor

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 maybecastprofiledreceiver(). It’s the exactness of the array element klass type. Here is the normal scenario: In Parse::arraystorecheck() 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 gencheckcast(). The maybecastprofiledreceiver() 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 (SSCalwaystrue) 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, maybecastprofiledreceiver() 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::arraystorecheck(). So when we recompile we skip the opportunity to assert the exactness of the klass of the array (toomanytraps(Deoptimization::Reasonarraycheck) == 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 gencheckcast() and into maybecastprofiledreceiver() 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 staticsubtypecheck() does not return SSCalwaystrue and typecheckreceiver() is not generated? typecheckreceiver() 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

More information about the hotspot-compiler-dev mailing list