RFR(S) 8166750: profiling handles statically bindable call sites differently than the interpreter
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.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.
> Igor Veresov wrote:
>> Sure. I’ve updated the webrev:
>> Also added a comment in HotSpotMethodData.java per Doug’s request.
>>> On Oct 25, 2017, at 10:29 AM, Vladimir Kozlov
>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>> 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
>>> 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
More information about the hotspot-compiler-dev