RFR: 8348853: Fold layout helper check for objects implementing non-array interfaces

[Tobias Hartmann]

On Wed, 26 Mar 2025 09:16:17 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> If `TypeInstKlassPtr` represents an array type, it has to be `java.lang.Object`. From contraposition, if it is not `java.lang.Object`, we can conclude it is not an array, and we can skip some array checks, for instance.
> 
> In this PR, we improve this deduction with an interface base reasoning: arrays implements only Cloneable and Serializable, so if a type implements anything else, it cannot be an array.
> 
> This change partially reverts the changes from [JDK-8348631](https://bugs.openjdk.org/browse/JDK-8348631) (#23331) (in `LibraryCallKit::generate_array_guard_common`) and the test still passes.
> 
> The way interfaces are check might be done differently. The current situation is a balance between visibility (not to leak too much things explicitly private), having not overly general methods for one use-case and avoiding too concrete (and brittle) interfaces.
> 
> Tested with tier1..3, hs-precheckin-comp and hs-comp-stress
> 
> Thanks,
> Marc

@rwestrel Should have a look at this :)

Please add an IR framework test that verifies that layout helper checks are optimized.

src/hotspot/share/opto/type.cpp line 3684:

> 3682: }
> 3683: 
> 3684: bool TypeInterfaces::has_non_array_interface() const {

What about using `TypeAryPtr::_array_interfaces->contains(_interfaces);` instead?

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

Changes requested by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24245#pullrequestreview-2722219539
PR Review Comment: https://git.openjdk.org/jdk/pull/24245#discussion_r2016955402