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

Igor Veresov igor.veresov at oracle.com
Thu Oct 26 19:42:52 UTC 2017

Good points, since I already push it, I’ll file a new bug.


> On Oct 26, 2017, at 9:48 AM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> Sorry I'm late to this, but I don't think the HotSpotMethodData changes are correct.  If you run with -XX:TypeProfileWidth=1 you'll get incorrect profiles for non-statically bindable call sites.  Shouldn't it be entries == 1 && methods[0].canBeStaticallyBound()?  I think the ciMethod workaround for this problem has the same issue.  Also I think it would make sense to null out the entry so it looks the same as a properly profiled vfinal call site.
> tom
> Igor Veresov wrote:
>> Sure. I’ve updated the webrev:
>> http://cr.openjdk.java.net/~iveresov/8166750/webrev.02/
>> Also added a comment in HotSpotMethodData.java per Doug’s request.
>> igor
>>> On Oct 25, 2017, at 10:29 AM, Vladimir Kozlov
>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>> Igor
>>> Can you factor out checks into boolean function in shared place? May
>>> be move some surrounding code into it too - I see the same code on all
>>> platforms.
>>> Thanks,
>>> Vladimir
>>> On 10/24/17 8:52 PM, Igor Veresov 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/
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8166750
>>>> Thanks,
>>>> igor

More information about the hotspot-compiler-dev mailing list