Unsafe vs MemorySegments / Bounds checking...

[Ioannis Tsakpinis]

> MethodHandle intrinsics (which are used in the implementation of var
> handles as well) are inlined incrementally [1]. This means that the
> calls are not inlined during parsing, based on a budget of bytecode
> counts, like regular methods. Essentially, C2 will hold off on inlining
> these calls, and then does a sequence of optimize, inline, optimize,
> inline, to try and inline as much as possible, based on a budget of
> total  live nodes in the compilation. This works well for method handles
> (and by extension var handles), because a lot of the code will
> evaporate/be optimized away. While C2 is inlining incrementally, the
> cutoff is temporarily increased as well [2].

The problem in this case though isn't bytecode size or live node count.
The inlining failure happens because a non-intrinsic & non-force-inline
method is called within the VarHandle that has crossed the max inline
level threshold. Afaict, the max inline level is indeed adjusted for
intrinsic methods, but it's only a +1 for each such method. This is
desirable, because they do not contribute to inlining decisions, but
there is no "level reset" or some other kind of adjustment that would
benefit non-intrinsic methods called within the VarHandle.

FWIW, I've added a comment with the +PrintInlining output for the first
benchmark that has an "inlining too deep" failure and the corresponding
JITWatch screenshot [1]. In this case the failure happens for
Module::isNamed, which is called deep within MemorySegment::reinterpret.

- Ioannis

[1]:
https://gist.github.com/Spasi/513d57fc608d9b91bcd73751e71491d1?permalink_comment_id=5267776#gistcomment-5267776