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

[Vladimir Kozlov]

Roland,

I need more time to go through methoddate.?pp changes.
Here some preliminary comments.

I think you need to use orptr(mdo_adr, obj) when storing klass first 
time to preserve sticky bit null_seen which could be set by other thread 
during small window. But it is still not atomic.
It would be even better if you set these sticking flags in a separate 
field (may be in stack_slot_entry which does not change, may be split in 
2 field). Or may be use atomic cmpxchg.
Then we would not worry about concurrent updates from different threads.

c1_LIRAssembler_x86.cpp: could you clean up ifdefs?:

+     if (do_update) {
+ #ifndef ASSERT
+       __ jmpb(next);
+ #else
+       __ jmp(next);
+ #endif
+     }
+   } else {
+ #ifdef ASSERT
+     __ testptr(tmp, tmp);
+     __ jccb(Assembler::notZero, update);
+     __ stop("unexpect null obj");
+ #endif
+   }

for example:

+     if (do_update) {
+ #ifndef ASSERT
+       __ jmpb(next);
+     }
+ #else
+       __ jmp(next);
+     }
+   } else {
+     __ testptr(tmp, tmp);
+     __ jccb(Assembler::notZero, update);
+     __ stop("unexpect null obj");
+ #endif
+   }

Indention in c1_LIRGenerator.cpp in sig_next_klass():

+   if (first_sig_k != NULL) {
+      sig_k = first_sig_k;
+     first_sig_k = NULL;


java.cpp can you also print mdo size per method before (or after) 
invocation counters? I assume you want to print more statistic with new 
flag later. If it is only size then we may not need a new flag (we have 
too many of them already).

TypeProfile is very general name and can be confusing. Current code 
already does type profiling: UseTypeProfile. TypeProfileLeveL?

Also add new flags into /* compiler */ section of globals.hpp where 
other TypeProfile flags are defined.

Thanks,
Vladimir

On 10/2/13 10:02 AM, 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.
>
> Roland.
>
>