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

[Christian Thalinger]

On Nov 10, 2011, at 6:00 PM, Vladimir Kozlov wrote:

> You can check failing() and return NULL in that case (most cases)

Done.

> 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.

The direct call is now generated by CallGenerator::for_method_handle_call.  Before we were just returning NULL if the inlining failed.

-- Chris

> 
> 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
>>