Aligning ReceiverTypeData for JVMCI, C1 and C2

[Vladimir Kozlov]

First, C1 does not use profile data.

Second, CounterData::count field is incremented on overflow only for 
virtual calls (it is used only for virtual call in such case):

     int non_profiled_offset = -1;
     if (is_virtual_call) {
       non_profiled_offset = in_bytes(CounterData::count_offset());
     }

And it is decremented only for type casts (aastore, checkcast, 
instanceof) because profile_typecheck_failed() is called only from 
gen_subtype_check().

So the comment is wrong, should be:

   // ReceiverTypeData for instanceof/checkcast/aastore:
   //   C1/C2: count is decremented for failed type checks

I think it is answering you 1. question.

Based on that your 2 statement is wrong in the sense that 'count' should 
not be incremented for type checks. Actually JVMCI comments are correct.

Regards,
Vladimir

On 8/11/16 6:03 AM, Doug Simon wrote:
> While investigating comments on https://bugs.openjdk.java.net/browse/JDK-8156137, I was reacquainted with this comment in methodData.hpp:
>
> class ReceiverTypeData : public CounterData {
>   friend class VMStructs;
>   friend class JVMCIVMStructs;
> protected:
>   enum {
> #if INCLUDE_JVMCI
>     // Description of the different counters
>     // ReceiverTypeData for instanceof/checkcast/aastore:
>     //   C1/C2: count is incremented on type overflow and decremented for failed type checks
>     //   JVMCI: count decremented for failed type checks and nonprofiled_count is incremented on type overflow
>     //          TODO (chaeubl): in fact, JVMCI should also increment the count for failed type checks to mimic the C1/C2 behavior
>     // VirtualCallData for invokevirtual/invokeinterface:
>     //   C1/C2: count is incremented on type overflow
>     //   JVMCI: count is incremented on type overflow, nonprofiled_count is incremented on method overflow
>
>     // JVMCI is interested in knowing the percentage of type checks involving a type not explicitly in the profile
>     nonprofiled_count_off_set = counter_cell_count,
>     receiver0_offset,
> #else
>
> A number of questions arose and Roland and I refreshed our understanding of this code:
>
> 1. How does C2 use the `count` field? It seems to have dubious value as it is both *incremented* on type overflow and *decremented* on failed type checks (we’ve confirmed the implementation matches this, at least on x86). If overflow types always cause failed type checks, the `count` field will be 0. Isn’t there a risk C2 interprets that to mean that only types in the profile were seen? I believe that it’s for this reason, the original author of the JVMCI code added the `non_profiled_count` field so we can tell if the profile provides full coverage of the seen types. If a profile is “complete”, Graal places a guard that deoptimizes if any other type is seen.
>
> 2. When EnableJVMCI is true, the current implementation never updates the `count` field for type overflow, only the `non_profiled_count` (the TODO comment should read “... should also  increment the count for failed type checks... “). Depending on how C1 and C2 use the `count` field, this may have adverse effects.
>
> To clear this up, I propose that the `non_profiled_count` field be made unconditional. However, before doing so we need to better understand how C1 and C2 use the `count` field and what changes would be needed to have them use `non_profiled_count`. Failing that, we should make the interpreter update `count` (in addition to `non_profiled_count`) for type overflows when JVMCI is enabled to avoid adverse consequences for C1 and C2.
>
> -Doug
>