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

[Lindenmaier, Goetz]

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.
>