request(S): 7066339: Tiered: policy should make consistent decisions about osr levels

Igor Veresov igor.veresov at
Sun Jul 17 14:32:03 PDT 2011

I modified the fix a little bit. With -Xcomp we had inconsistent 
behavior with tiered and TieredStopAtLevel. Everything was compiled at 
level 3 regardless of TieredStopAtLevel flag value. I've added 
CompilationPolicy::initial_compile_level() to make it policy-dependent.


Sorry for the noise.


On 7/14/11 1:04 PM, Igor Veresov wrote:
> Thanks Vladimir and Tom!
> igor
> On 7/14/11 12:42 PM, Tom Rodriguez wrote:
>> Looks ok.
>> tom
>> On Jul 13, 2011, at 6:49 PM, Igor Veresov wrote:
>>> After my fix for 7058689 it is possible that the
>>> AdvancedThresholdPolicy will make a different decision as to what
>>> compilation level for osr is appropriate in loop_event() and
>>> call_event() from what happens in method_back_branch_event(). In
>>> method_back_branch_event() in case the OSR compilation level is
>>> CompLevel_limited_profile we change it to CompLevel_full_profile but
>>> we don't do the same in call_event() and loop_event() to determine
>>> whether the existing OSR methods are current. The solution would be
>>> to move this level fixup in form of disabling the tier 3 delay
>>> feedback in common() for OSRs.
>>> There was also bad interaction between the in-queue level change
>>> optimization with TieredStopAtLevel option set to 3, which caused
>>> compilation loops between level 2 and 3. Now it will be disabled if
>>> TieredStopAtLevel< 4.
>>> Also moved handling of TieredStopAtLevel to common(), because when it
>>> was in compile() it could lead to unnecessary OSR compiles with
>>> TieredStopAtLevel< 4.
>>> Webrev:
>>> Thanks,
>>> igor

More information about the hotspot-compiler-dev mailing list