Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not

[Vladimir Kozlov]

You can check failing() and return NULL in that case (most cases) otherwise generate direct call if inlining failed for 
an other reason. I still do not get why hot path do not do it, it also can fail because of nodes threshold.

Vladimir

On 11/10/11 3:28 AM, Christian Thalinger wrote:
>
> On Nov 9, 2011, at 4:15 PM, Vladimir Kozlov wrote:
>
>> Why not generate direct call as we do we for hot call?
>
> I had a small chat with John about that yesterday.  Maybe moving the logic into its own function that returns a direct/dynamic call instead of null when the inlining fails is in general a good idea (especially for the selectAlternative idiom).  I updated the webrev with that code.
>
> But in this particular case it doesn't help since we are so close (or already over) the threshold cliff that it fails anyway.  Let me know what you think.
>
> -- Chris
>
>
>>
>> Vladimir
>>
>> Christian Thalinger wrote:
>>> http://cr.openjdk.java.net/~twisti/7108383/
>>> 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not
>>> Reviewed-by:
>>> The problem is that the code in
>>> PredictedDynamicCallGenerator::generate assumes that the generation of
>>> the slow path always succeeds.  This might not be the case when we hit
>>> the node limit while generating the slow path.
>>> The suggested fix is to remove the assert and return on failed slow
>>> path generations.
>>> I also applied the fix to PredictedCallGenerator::generate because I
>>> think it can also happen there.
>>> src/share/vm/opto/callGenerator.cpp
>