RFC: 8023657: Extra type profiling points could help C2 code generation

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Aug 23 15:47:46 PDT 2013


Roland,

Can you show an example of new mdo data (from print_codes())?

You need to describe where new info is recorded so we don't need to 
search for it.

 From what I see MethodArgs are recorded at the end of MDO. CallArgs and 
CallRet are recorded together with Call's receiver klass data (receiver 
is simple first argument). Right?

Why do you need 2 cells per arg when you record only one type without 
counter? What is arg_off_rel_off for?

  737   enum {
  738     arg_off_rel_off,
  739     arg_type_rel_off,
  740     per_arg_cell_count
  741   };

Why not reuse ReceiverTypeData for all new data (you used it only for 
VirtualCallArgs)?

What next fields are for? I don't see constructor is called.

TypeDataAtCall {
    const int _base_off;
    ProfileData* _pd;

"Parameters refers to the list of variables in a method declaration. 
Arguments are the actual values that are passed in when the method is 
invoked."

May be:

TypeProfileCallArgs --> TypeProfileArgs
TypeProfileCallRet  --> TypeProfileRet
TypeProfileMethodArgs --> TypeProfileParams

Definitely:

TypeProfileNbCallArgs --> TypeProfileArgsLimit

thanks,
Vladimir

On 8/23/13 8:02 AM, Roland Westrelin wrote:
> John suggested I send this out for pre-review.
>
> This change adds extra type profiling: a limited number of incoming arguments to methods, return values from calls, a limited number of arguments passed to calls. Only x86 interpreted is implemented here and there's no code on the c2 side to take advantage of the extra profiling (that's something I'm working on in a separate change). The code lacks comments and can probably be cleaned up so this is not a request for an in depth review. Profiling of arguments to calls may be limited to a subset of methods in the final change (in order to limit the footprint increase and impact on start up) depending on what we find is necessary to help code generation.
>
> http://cr.openjdk.java.net/~roland/8023657/webrev.00/
>
> Roland.
>


More information about the hotspot-compiler-dev mailing list