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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Sun Sep 15 14:19:46 PDT 2013

Hi Coleen, 

thanks for the hint, I adapted the webrev.
Looks better like that.

Best regards,

-----Original Message-----
From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillmore
Sent: Sunday, September 15, 2013 4:13 PM
To: hotspot-dev at openjdk.java.net
Subject: Re: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling

This isn't a full review but can you refactor 
InterpreterRuntime::note_trap() so that there isn't duplicated code?    
It doesn't seem like there are enough differences for a separate function.


On 9/15/2013 9:58 AM, Lindenmaier, Goetz wrote:
> 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.

More information about the ppc-aix-port-dev mailing list