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

[Christian Thalinger]

src/share/vm/ci/ciStreams.hpp:

+     if (_holder != NULL) {
+       sig_k = _holder;
+       _holder = NULL;
+     } else {

Instead of clearing _holder can you use pos to see if we are at the first position?

src/share/vm/runtime/signature.cpp:

+ int SignatureStream::reference_parameter_count(int max) {

Don't pass in max.  This is only applicable to your use case.  Do the max check inline.

+      profiled_k = TypeEntries::with_status((intptr_t)result, profiled_k);

+      return TypeEntries::with_status((intptr_t)klass, k);

These two still use the intptr_t version.

On Oct 7, 2013, at 7:46 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> Vladimir, Thanks for your comments.
> 
>> I need more time to go through methoddate.?pp changes.
> 
> Sure. Here is a new webrev that addresses Christian's comments and yours below.
> 
> http://cr.openjdk.java.net/~roland/8023657/webrev.02/
> 
>> 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.
> 
> In one of the follow up changes I will do profiling of the type of return values. For them there's not need of keeping track of the stack slot so we can't assume that there's an extra entry in the MDO for each type.
> 
> Roland.
> 
>> 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.
>>> 
>>> 
>