RFR(M): 8031754: Type speculation should favor profile data from outermost inlined method

Roland Westrelin roland.westrelin at oracle.com
Thu Jan 23 07:06:25 PST 2014


Thanks for looking at this, Vladimir.

>> My wild guess is that the outermost method generally gives you the best
>> (cleanest) context information. The inner callees may have been called
>> from various callers, and so their type profiles may have been polluted
>> by other callers.
> 
> They can't be polluted. We record only one speculative type. If Interpreter see a different type it will set flags and that type information will not be used. At least that is how I understand it works. That is why I am asking Roland to clarify this.

That’s the way they work. What can happen for this (and what happens sometimes I believe):

m1() {
  m3();
}

m() {
 m1();
 m2();
}

is that m3() is a heavily used method called from some other place early during the application run. Some profile is recorded. The method becomes so hot that it gets compiled with c2. So we stop profiling. Then m3() is called from m1() but because it’s already compiled we don’t record the conflicting profile. When m() is compiled we are stuck with an incorrect profile and we may miss some optimization opportunities. 

As Krys said, intuitively "the outermost method generally gives you the best (cleanest) context information”. It’s only a heuristic and as such, it’s certainly easy to build a test case for which this heuristic doesn’t do a good job. It does help for experiments I made with nashorn so I’d like to see it used to confirm it does help.

Roland.


> 
> If you have merging case:
> 
> if (x)
>  m1()
> else
>  m2()
> 
> I don't understand why at merge point information from m2 will be more precise then from m3() called from m1().
> 
> Thanks,
> Vladimir
> 
>> 
>> - Kris
>> 
>> 
>> On Wed, Jan 22, 2014 at 7:51 PM, Vladimir Kozlov
>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>> 
>>    Roland,
>> 
>>    I don't see how inlining depth can define type's accuracy in general
>>    case. why it can't be reverse: more accurate type from most deeply
>>    inlined method?
>> 
>>    I thought you only have speculative type if it is the only one type
>>    record in MDO. How in your case you can have different types?
>> 
>>    Can you be more specific?
>> 
>>    Thanks,
>>    Vladimir
>> 
>> 
>>    On 1/22/14 1:42 AM, Roland Westrelin wrote:
>> 
>>        When a node already has a speculative type, and parsing
>>        encounters extra profiling data, the new profiling data is
>>        ignored. So profiling data coming from profile points closer to
>>        the root of the compilation is favored which I think makes
>>        sense: it's the data that is most specific to the context of
>>        this compilation.
>> 
>>        During runs, profile data is not always entirely coherent so we
>>        may hit something like this:
>>        m1() {
>>             m3();
>>        }
>> 
>>        m() {
>>            m1();
>>            m2();
>>        }
>> 
>>        With: m3() and m2() have profile data for the same node. The
>>        first profile data to be encountered during parsing is from m3()
>>        and profile data from m2() is ignored but profile data from m2()
>>        is the one that is actually the most specific and is the one
>>        that should be favored.
>> 
>>        When a speculative type is created, this change records the
>>        inline depth at which the profile point is. The inline depth is
>>        then propagated together with the rest of the type information.
>>        When new profile data is available for a node that already has a
>>        speculative type, the current inline depth and the inline depth
>>        of the current speculative type are used to decide whether the
>>        new data should be used to replace the existing speculative type.
>> 
>>        This change helps stabilize performance with nashorn.
>> 
>>        http://cr.openjdk.java.net/~__roland/8031754/webrev.00/
>>        <http://cr.openjdk.java.net/~roland/8031754/webrev.00/>
>> 
>>        Roland.



More information about the hotspot-compiler-dev mailing list