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

[Vladimir Kozlov]

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.
>
>