If `ProfileTraps` is enabled (which is the default) the interpreter will profile null pointer exceptions. This profiling data will be used during compilation to avoid uncommon traps, deoptimizations and recompilations for exceptions which occurred before (i.e. are "hot").

However, this currently only works for field accesses but not for calls. In the following example:

  static class Value {
    int i;
  }
  static int f(Value v) {
    return v.i;
  }
  static int g(Value v) {
    return v.hashCode();
  }

  public static void main(String[] args) {
    for (int i = 0; i < 20_000; i++) {
      try {
        f(null);
        g(null);
      }
      catch (NullPointerException npe) { }
    }
  }

`f()` will be compiled with without an uncommon trap for `v.i` while `g()` will have an uncommon trap for `v.hashCode()`. This will lead to `PerBytecodeTrapLimit` deoptimizations and finally the recompilation of `g()` if it will be called with a NULL argument.

The same is true for `array_check` traps. Currently they are recorded as `class_check` trap in the interpreter and therefore not detected as hot when a compilation happens. This also results in `PerBytecodeTrapLimit` deoptimizations (with reason `array_check`) before the exception will be recognized as hot in the recompilation.