RFR(S) 8166750: profiling handles statically bindable call sites differently than the interpreter

[Igor Veresov]

> On Oct 25, 2017, at 3:07 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
>  581 
>  582             // Fixup the case of C1's inability to optimize profiling of a statically bindable call site
>  583             if (entries == 1) {
>  584                 counts[0] = totalCount;
>  585             }
>  586 
> But what happens if we're looking at a profile from the interpreter? In that case, won't totalCount == 0 && counts[0] have the right value? In which case, the above fixup will lose this information. Maybe it should be:
> 
>     counts[0] += totalCount;


If it’s pure interpreter you’d have entries == 0, so this fixup won’t fire. Also totalCount at the point of the fixup is a sum of every counter in profile (for all the types + the counter for types that weren’t recorded). So what the fixup does is that it attributes all the counts to the first type (if it’s a monomorphic call site).

igor

> 
> -Doug
> 
>> On 25 Oct 2017, at 05:52, Igor Veresov <igor.veresov at oracle.com <mailto:igor.veresov at oracle.com>> wrote:
>> 
>> This a fix from Tom that I ported to all architectures and the new repo structure. While that fix doesn’t not solve the problem of the interpreter-C1 profiling style discrepancy completely it speeds up profiling of the statically bindable call sites and we’d like to push that. I also added a bit of a code to JVMCI to do the profile fix up analogous to what happens in CI.
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8166750/webrev.01/ <http://cr.openjdk.java.net/~iveresov/8166750/webrev.01/>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8166750 <https://bugs.openjdk.java.net/browse/JDK-8166750>
>> 
>> Thanks,
>> igor
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20171025/1efc337f/attachment-0001.html>