RFR(L): 8024070: C2 needs some form of type speculation

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Oct 8 10:34:14 PDT 2013

Test produce correct results (1+2==3; the result could be wrong, for 
example, when an incorrect method is inlined because incorrect receiver 
type was used) and no assert (crushes). I don't ask to verify 
inlining/not_inlining decisions.


On 10/8/13 9:35 AM, Roland Westrelin wrote:
> Hi Vladimir,
>>>> You need to add jtreg tests to verify these changes for different cases (especially merge points with different profile types).
>>> Do you mean tests that show an improvement (artificially pollute profiling at a call site and verify that some profiling that dominates the call site helps for instance)? I have such tests but they need manual inspection of the resulting code or inlining. Given the effect of the change has no visible effects at the java level how would I automate testing? Run with -XX:+PrintInlining and parse the output? Have we done that before on other tests?
>> No. I just want to test correctness. Something like merging array and instance types, reflection, constant types etc. To make sure your new code in C2 types works correctly (correct inlining). Use test cases which you think can be problematic. Even if a test doesn't fail with your current changes we need it.
> This is still not clear to me.
> Do you want tests to test correctness as in no VM crash or correctness as in correctly optimized?
> Maybe you can sketch a example test?
> Roland.

More information about the hotspot-compiler-dev mailing list