RFR(M): 8026251: New type profiling points: parameters to methods

[Christian Thalinger]

Since InterpreterMacroAssembler::profile_parameters_type is basically them exact same code (except movl/neql vs. movq/negq and rdi vs. r14) can we create new files:

src/cpu/x86/vm/interp_masm_x86.{cpp,hpp}

and put the method there?  I did a quick experiment locally and there is no problem.  We should stop duplicating code.

src/share/vm/oops/methodData.hpp:

+   // Offset with the MDO for the area dedicated to
+   // parameters. -1 if no parameter profiling.
+   int _parameters_type_data_di;

What's "di"?  Please rename.

src/share/vm/runtime/globals.hpp:

+           "X, Y and Z in 0->off ; 1->js292 only; 2->all methods")           \

Typo "js292".  Maybe use "=" instead of "->".

Are we printing the flag comments somewhere?  If yes, then printing this will look very odd:

!           "=XYZ, with Z, Type profiling of arguments at call"               \
!           "           Y, Type profiling of return value at call"            \
!           "           X, Type profiling of parameters to methods"           \
+           "X, Y and Z in 0->off ; 1->js292 only; 2->all methods")           \

Since it will be one string without new lines or spaces.  Same with this one:

+   product(intx, TypeProfileParmsLimit,    2,                                \
+           "max number of incoming parameters to consider for type profiling"\
+           "-1 for all")                                                     \

Otherwise this looks good.

On Oct 18, 2013, at 9:26 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level.
> 
> http://cr.openjdk.java.net/~roland/8026251/webrev.03/
> 
> Roland.
> 
> 
> On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> It is good. Thank you for this.
>> 
>> Vladimir
>> 
>> On 10/17/13 11:44 AM, Roland Westrelin wrote:
>>> Here is a new webrev with more comments.
>>> 
>>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/
>>> 
>>> Roland.
>>> 
>>> 
>>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>>> On 10/14/13 2:19 PM, Roland Westrelin wrote:
>>>>> 
>>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>> 
>>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote:
>>>>>>> Hi Vladimir,
>>>>>>> 
>>>>>>> Thanks for the comments.
>>>>>>> 
>>>>>>>> I wish you added more comments to the code.
>>>>>>> 
>>>>>>> Do you want me to send another webrev?
>>>>>> 
>>>>>> I would wait review from Christian before updating webrev.
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1.
>>>>>>>> 
>>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments?
>>>>>>> 
>>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call.
>>>>>> 
>>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?:
>>>>>> 
>>>>>> arg = x->profiled_arg_at(i);
>>>>> 
>>>>> Yes.
>>>> 
>>>> Okay.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>>> 
>>>>> Roland.
>>>>> 
>>>>>> 
>>>>>> Vladimir
>>>>>> 
>>>>>>> 
>>>>>>>> methodData.cpp Rename args_cell to params_cell:
>>>>>>>> 
>>>>>>>> +   int args_cell = ParametersTypeData::compute_cell_count(method());
>>>>>>>> +   if (args_cell > 0) {
>>>>>>> 
>>>>>>> Ok.
>>>>>>> 
>>>>>>> Roland.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>> 
>>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote:
>>>>>>>>> The last of the series of new type profiling points.
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/
>>>>>>>>> 
>>>>>>>>> The output of PrintMethodData is:
>>>>>>>>> 
>>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object;
>>>>>>>>>  interpreter_invocation_count:     5000
>>>>>>>>>  invocation_counter:               5000
>>>>>>>>>  backedge_counter:                    0
>>>>>>>>>  mdo size: 444 bytes
>>>>>>>>> 
>>>>>>>>>  parameter types                   0: stack(0) 'TestProfiling'
>>>>>>>>>                                    1: stack(1) 'TestProfiling$A'
>>>>>>>>> 
>>>>>>>>> Roland.
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>