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

Igor Veresov igor.veresov at oracle.com
Wed Oct 25 16:13:47 UTC 2017

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


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

More information about the hotspot-compiler-dev mailing list