[14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type"

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Oct 24 16:55:43 UTC 2019


I would like to see what happens with MDO data with Tobias fix which caused regression. If it is simple. May be from 
LogCompilation.

Original fix for 6923002 explicitly assumed [1] that we will get monomorphic in such case (we record 2 types and 
cleaning one and leaving only one). Total count will be adjusted anyway if needed [2].

The only explanation I can think of if we had only one receiver in MDO which we cleaned up and it confuse C2 to treat 
call site as never executed [3] so that it can't use speculative_receiver_type which come from other data.

Your fix seems reasonable and explains why it may help even so there is no type information in MDO, only count.

Thanks,
Vladimir

[1] http://hg.openjdk.java.net/jdk/jdk/file/32d39d9525f9/src/hotspot/share/oops/methodData.hpp#l1158
[2] http://hg.openjdk.java.net/jdk/jdk/file/32d39d9525f9/src/hotspot/share/ci/ciMethod.cpp#l534
[3] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l205

On 10/24/19 3:04 AM, Christian Hagedorn wrote:
> Hi
> 
> Please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8230019
> http://cr.openjdk.java.net/~chagedorn/8230019/webrev.00/
> 
> This is an optimization of the previous fix [1, 2] which had a negative impact on performance. A complete explanation of 
> the problem and the original fix can be found at [3].
> 
> In this patch, only the receiver klass information is cleared (which was the source of the assertion failure) instead of 
> using clear_row() which also cleared the total count of the profile data as done in the fix of 8225670. I assume this 
> prevented some inlining decisions which relied on reading such a cleared counter as in Compile::call_generator() [4]. 
> This patch had no negative impact on performance anymore (verified with regressing benchmarks).
> 
> Thank you!
> 
> Best regards,
> Christian
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8225670
> [2] http://cr.openjdk.java.net/~thartmann/8225670/webrev.00/
> [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-August/034776.html
> [4] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l85


More information about the hotspot-compiler-dev mailing list