Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not
vladimir.kozlov at oracle.com
Thu Nov 10 09:00:23 PST 2011
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.
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