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

[Tom Rodriguez]

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
>