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