RFR(L) 8026054: New type profiling points: type of return values at calls

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Oct 8 16:14:26 PDT 2013


Roland,

Sorry, but I will not be able to debug this in 3 month :( 
TypeStackSlotEntries is already complex enough and you including return 
type cell into it (by using TypeEntriesAtCall) to avoid additional cell 
when no object return.

Can we always have one separate cell for return value for CallTypeData 
and VirtualCallTypeData when arguments are profiling. I would prefer to 
have that cell always instead of complicated code which tries to 
calculate its presence. From what I understand when you profile only one 
argument TypeProfileArgsLimit=1 you will use additional cell for cells 
count even if no return will be recorded (if return type is not profiled 
cell count is not added in this case). It looks like the space usage 
will be the same as when you always generate cell for return type for 
this case (for 2 and more arguments you will get extra one but it is 
3+1). I think it will simplify the code because you don't need to change 
TypeStackSlotEntries.

So can you separate TypeStackSlotEntries and ReturnTypeEntry and don't 
use TypeEntriesAtCall?:

   class VirtualCallTypeData : public VirtualCallData {
   private:
!   TypeStackSlotEntries _args;
!   ReturnTypeEntry       _ret;

Yes, CallTypeData and VirtualCallTypeData will have more additional 
duplicated code. You can put some common code into TypeEntries (for 
example, compute_cell_count() is static).

And TypeStackSlotEntries should be ArgTypeEntries because stack slot is 
just data used to record arguments types.

Thanks,
Vladimir

On 10/8/13 9:22 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8026054/webrev.00/
>
> Follow up to 8023657: New type profiling points: arguments to call
>
> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence.
>
> The output of PrintMethodData is:
>
> 17 invokevirtual 3 <TestProfiling.m2(LTestProfiling$C;Ljava/lang/Object;Ljava/lang/Object;)LTestProfiling$C;>
>    16  bci: 17   VirtualCallData     count(0) entries(1)
>                                      'TestProfiling'(4744 1.00)
>                  argument types      0: stack(1) 'TestProfiling$C'
>                                      1: stack(2) 'TestProfiling$B'
>                  return type         'TestProfiling$C'
>
> Roland.
>


More information about the hotspot-compiler-dev mailing list