RFR: 8320308: C2 compilation crashes in LibraryCallKit::inline_unsafe_access

[Vladimir Ivanov]

On Wed, 4 Sep 2024 17:23:54 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I reconsidered my conclusion about root cause.

I'd like to clarify one point here: I still think speculative types may disturb exact checks against preallocated type constants [1] [2]. As an example, `TypePtr::cleanup_speculative()` [3] has to align `inline_depth()` in order to make comparison with `NULL_PTR` to work accurately.  

It doesn't look like `NULL_PTR` is affected (since `TypePtr::cleanup_speculative()` unconditionally drops speculative part for it), but `Type*::BOTTOM`/`Type*::NOTNULL` et all seem susceptible to the problem.  @rwestrel, what do you think?

[1]
> IMO the root problem is in LibraryCallKit::classify_unsafe_addr() where base_type == TypePtr::NULL_PTR doesn't hold in presence of speculative part

[2]
> Initially, I had only == TypePtr::NULL_PTR comparisons in mind, but on a second thought all comparisons with preallocated type constants are susceptible to false negatives in presence of speculative part.

[3]

const Type* TypePtr::cleanup_speculative() const {
  if (speculative() == nullptr) {
    return this;
  }
  const Type* no_spec = remove_speculative();
  // If this is NULL_PTR then we don't need the speculative type
  // (with_inline_depth in case the current type inline depth is
  // InlineDepthTop)
  if (no_spec == NULL_PTR->with_inline_depth(inline_depth())) {
    return no_spec;
  }
  if (above_centerline(speculative()->ptr())) {
    return no_spec;
  }
  const TypeOopPtr* spec_oopptr = speculative()->isa_oopptr();
  // If the speculative may be null and is an inexact klass then it
  // doesn't help
  if (speculative() != TypePtr::NULL_PTR && speculative()->maybe_null() &&
      (spec_oopptr == nullptr || !spec_oopptr->klass_is_exact())) {
    return no_spec;
  }
  return this;
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20033#issuecomment-2329745385