Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not
christian.thalinger at oracle.com
Wed Nov 16 05:45:39 PST 2011
On Nov 10, 2011, at 6:00 PM, Vladimir Kozlov wrote:
> 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.
The direct call is now generated by CallGenerator::for_method_handle_call. Before we were just returning NULL if the inlining failed.
> 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
>>> Christian Thalinger wrote:
>>>> 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not
>>>> 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.
More information about the hotspot-compiler-dev