RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling

[Vladimir Kozlov]

Yes, this looks good.
I think we should use JPRT this time to verify that this and previous changeset are clean.
Anyway we need to wait when Iris resolves the problem with last changeset.

Thanks,
Vladimir

On 10/1/13 3:54 PM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
> I updated the webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8024468-profile/
>
>> TraceProfileInterpreter may be not good name. I first thought you implemented bytecodes trace profiling :)
>> Can you change at least flag's comment to be clear that it is printing?
> I added some more text.  Actually we just copied the text from "ProfileInterpreter" ;)
>
>> Can you put under #ifdef CC_INTERP methods in invocationCounter.hpp which are used only by cppInterpreter?
> Done for the ones I edited.  There seem to be several dead methods.
> Should I clean them up?  So far they should be removed by the
> C++ compiler.
>
> I also changed an #ifdef in jvmtiManageCapabilities.cpp from
> CC_INTERP to ZERO. I already had the correspondent change in
> arguments.cpp in this webrev, but had missed that one.
>
> Best regards and thanks for the review!
>    Goetz
>
>
>
> In general it is good I think.
>
> thanks,
> Vladimir
>
> On 9/30/13 7:21 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> could I please get some reviews on this change?  Although this is marked 'L',
>> this should not be too much as most of the code is guarded by ifdef CC_INTERP.
>>
>> Thanks and best regards,
>>     Goetz.
>>
>> From: goetz.lindenmaier at sap.com
>> Sent: Sonntag, 15. September 2013 15:58
>> To: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov'
>> Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling
>>
>> Hi,
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8024468-profile/
>> this change implements bytecode profiling for the cppInterpreter.
>> It changes a row of shared files, but most of the changes are
>> guarded by CC_INTERP.  This is not mandatory, but I think it
>> makes clear what the extensions are meant for, and assures it's
>> not compiled into template interpreter builds.
>>
>> We desinged the bytecode profiling for the cppInterpreter
>> to deliver exact the same counter values as the template interpreter does.
>> E.g., we extended the interpreter to also check backedge counts.
>>
>> The macros used in the interpreter loop are placed in a new
>> file bytecodeInterpreterProfiling.hpp.  I'm happy to move them
>> somewhere else.
>>
>> The code is guarded with CC_INTERP_PROFILE, which is only enabled
>> if COMPILER2 is set. Thus, ZERO will not encounter any overhead
>> in the interpreter loop.
>>
>> This change also enables all the new features we implemented in
>> the cppInterpreter, see arguments.cpp.
>>
>> Although this change is marked as L, it should not have an effect
>> on non-cppInterpreter platforms.
>>
>> Please review and test this change.
>>
>> Best regards,
>>     Goetz.
>>