The PhaseTransform class has an optimization around ranges checks for the types array:

  // Make sure the types array is big enough to record a size for the node n.
  // (In product builds, we never want to do range checks on the types array!)
  void ensure_type_or_null(const Node* n) {
  [...]

  const Type *fast_lookup(uint i) const{assert(i<_max,"oob");return _types[i];}

If some code happens to create a new Node but forgets to map a type, or grow the array by calling ensure_type_or_null directly or indirectly, it could trigger an assert in fast_lookup(). The problem is *could*. It would be much better if we always detected this. As it is now, detection is most likely when the type array is full and not recently expanded, because immediately after expansion, the array size has been doubled, leaving the last half of the array with empty slots that prevent the fast_lookup from detecting unmapped nodes.

In a recent example (from JDK-8281299):

  RegionNode* result_reg = new RegionNode(PATH_LIMIT);
  PhiNode* result_mem = new PhiNode(result_reg, Type::MEMORY, TypePtr::BOTTOM);
  [...]
  set_all_memory(_gvn.transform(result_mem));

it may be difficult to see the error, and in the case of JDK-8281299, it only caused an assert when the type array size was at 512 and the new nodes had values >= 512. Assuming previously created nodes after already expanded the array, the problem with this code samples happens when result_reg has an index of exactly 512. If the index were less than 512, the assert would not fail. If the index were greater than 512, the previously created node would have expanded the array to size 1024. So we have a 1 in N/2 chance of failing here when the type array has size N.