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

[Krystal Mok]

Hi Vladimir,

Oops, then my wild guess was way off...
I haven't followed the recent addition of profiling and speculative types
so just ignore me on this one.

Sorry about the noise.

Thanks,
Kris


On Wed, Jan 22, 2014 at 8:05 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> On 1/22/14 7:57 PM, Krystal Mok wrote:
>
>> Hi 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.
>
> 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.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140122/50bd79f8/attachment.html