Aligning ReceiverTypeData for JVMCI, C1 and C2

[Doug Simon]

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