RFR(M): 8026251: New type profiling points: parameters to methods
Christian Thalinger
christian.thalinger at oracle.com
Mon Oct 21 20:15:16 PDT 2013
On Oct 21, 2013, at 12:34 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>
> Here is new webrev:
>
> http://cr.openjdk.java.net/~roland/8026251/webrev.04/
>
> See inlined:
>
> On Oct 18, 2013, at 7:23 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>
>> 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.
>
> I moved all the new profiling code to the new files.
Nice! Thanks for doing this.
>
>>
>> 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:
>
> -XX:+PrintFlagsWithComments does. I improved the formatting so that when printed it doesn't look too bad.
+ product(intx, TypeProfileParmsLimit, 2, \
+ "max number of incoming parameters to consider for type profiling, "\
+ "-1 for all") \
+ \
Could you align the "\" at the end of the lines? No need for a new webrev.
Otherwise this looks good.
>
> Roland.
>
>>
>> ! "=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.
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
More information about the hotspot-compiler-dev
mailing list