RFR(S): 8061817: Whitebox.deoptimizeMethod() does not deoptimize all OSR versions of method
vladimir.kozlov at oracle.com
Mon Oct 27 16:40:20 UTC 2014
I don't like adding deoptimization checks inside lookup method which
have nothing to do with deoptimization.
I would suggest to add new method InstanceKlass::mark_osr_nmethods() to
mark all related OSRs. We have already
InstanceKlass::mark_dependent_nmethods() but it could be not applicable
to all our tests if they don't record dependencies during OSR compilation.
On 10/27/14 7:45 AM, Tobias Hartmann wrote:
> Hi Igor,
> thanks for the review.
> On 24.10.2014 15:06, Igor Ignatyev wrote:
>> Hi Tobias,
>> 1. could you please make 'method' an instance field?
>> 2. use AssertionError instead of RuntimeException
>> 3. have you tried to run this test w/ Xcomp?
> Yes, it works fine (OSR compilations are still triggered and deoptimized).
> However, I found another bug and filed 8062169.
> New webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.01/
>> On 10/24/2014 04:39 PM, Tobias Hartmann wrote:
>>> please review the following patch.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061817
>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.00/
>>> 'WhiteBox.deoptimizeMethod' does not deoptimize all OSR compiled versions of the
>>> given method but only one. The problem lies in'WB_DeoptimizeMethod'. The call to
>>> 'lookup_osr_nmethod_for' only returns the best fitting OSR nmethod. Incrementing
>>> the bci (see line 395) does not help.
>>> I changed the implementation to deoptimize all OSR versions and added a
>>> regression test that triggers two OSR compilations and checks that both are
>>> deoptimized ('DeoptimizeMultipleOSRTest').
>>> New test on JPRT
More information about the hotspot-compiler-dev