review for 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb
Vladimir Kozlov
vladimir.kozlov at oracle.com
Wed Jun 22 14:06:34 PDT 2011
Tom Rodriguez wrote:
> On Jun 22, 2011, at 12:23 PM, Vladimir Kozlov wrote:
>
>> Is it possible to add an assert in nmethod::preserve_callee_argument_oops() to verify that invokedynamic has a receiver?
>
> Do you mean to verify that the receiver is really a valid oop or something else?
Yes, check for a valid oop since it will be GC'ed. What confused me is the
sentence: "at this point". Does it mean that at some point invokedynamic does
not have a valid receiver?
Thanks,
Vladimir
>
> tom
>
>> Otherwise looks good.
>>
>> thanks,
>> Vladimir
>>
>> Tom Rodriguez wrote:
>>> http://cr.openjdk.java.net/~never/7057587
>>> 40 lines changed: 6 ins; 0 del; 34 mod; 4861 unchg
>>> 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb
>>> Summary: don't skip receiver when GC'ing compiled invokedynamic callsites
>>> Reviewed-by:
>>> When GC'ing at a call site during resolution the arguments to the call
>>> have to be handled specially. In most cases the implicit receiver to
>>> method handle invoke is ignored but in this case it must be treated as
>>> real so that it is properly GC'ed. Tested with failing test from
>>> report. Also ran jck, regression tests and vm.mlvm tests.
>>> I also included a fix to the inline level printing. For method handle
>>> invokes we don't want to count them against MaxInlineLevel and
>>> previously this was done by adding a bias to the inline_depth. This
>>> screwed up the indenting making the inlining output unreadable.
>>> Instead we should keep the depth count consistent and adjust the max
>>> inline level for the subtree. This is done by keeping that value in
>>> the InlineTree. inline_depth was renamed to inline_level to be
>>> consistent with MaxInlineLevel.
>
More information about the hotspot-compiler-dev
mailing list