RFR(L): 8023657: New type profiling points: arguments to call

[Remi Forax]

On 10/02/2013 07:02 PM, Roland Westrelin wrote:
> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86.
>
> http://cr.openjdk.java.net/~roland/8023657/webrev.01/
>
> The output of -XX:+PrintMethodData is:
>
> 6 invokevirtual 2 <TestProfiling.m2(LTestProfiling$C;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;>
>    0   bci: 6    VirtualCallData     count(0) entries(1)
>                                      'TestProfiling'(4746 1.00)
>                  argument types      0: stack(1) 'TestProfiling$C'
>                                      1: stack(2) unknown (null seen)
>
> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling.
> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc.
> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps.

There is another case where this kind of profiling will be really helpful,
for methods that takes a lambda as parameter like by example 
HashMap.computeIfAbsent,
currently if this method is used more than 2 times with different lambdas,
the profile of the receiver of the call of the lambda (an 
invokeinterface) is polluted.

Detecting this kind of methods requires some work, the VM has to look 
for a method parameter which is a functional interface,
which mean that the VM has to have a way to detect if an interface is a 
functional interface,
but I think it worth the trouble.

> Roland.
>
>

Rémi