Unsafe vs MemorySegments / Bounds checking...

[rsmogura at icloud.com]

Hi all,

I'm not sure if proposition is like this:

In addition to @ForceInline, there can be @ForceParentCallsInline - to force inlining all calls from caller, as there are situations where performance issues are reported because „parent” (aka „caller’) uses to complicated method graphs.

Best regards,
Rado

> Wiadomość napisana przez Maurizio Cimadamore <maurizio.cimadamore at oracle.com> w dniu 30 paź 2024, o godz. 15:18:
> 
> Adding Vlad here.
> 
> In general this has always been a "known" issue with hotspot inlining - there are cases where we _know_ the resulting assembly is gonna be very good, but it takes a lot of work to get there, and the transient compilations might yield something that is too big - which means JIT will "give up".
> 
> This is why, AFAIU, method handles and var handles call are able to use a deeper inlining treshold compared to regular method calls (because if a MH or VH callsite can be inlined, the theory is that once we're done, the resulting assembly will be quite small).
> 
> Failure to inline has effects on different areas - the most egregious ones being escape analysis: if an object is passed to an out of line call, then it MUST be allocated.
> 
> Summing up --- inlining heuristics are complex and can misbehave. And when they do misbehave some performance loss can occur, which seems to be the case here.
> 
> FFM-wise, the important thing is that all the paths that originates from a VarHandle::get/set call are inlined as expected. If that is already the case (and we have many benchmarks to make sure that's the case -- but of course there could be corners we don't know about), then there's not much else our implementation can do on that front.
> 
> That's not to say that that 2% will always stay there. In the past we have raised the inlining depth for MH/VH calls, so, perhaps, with enough evidence that trick can be applied again. Or, perhaps someday some better inlining heuristics will replace the existing ones and overcome some of the limitations with the current approach. It seems to me one of those cases where "with time, things will get better" (as it's often the case with the JVM).
> 
> (But if you find any evidence that the code failing to inline belongs to FFM, that's something we might try and have a look at)
> 
> Maurizio
> 
> 
> On 30/10/2024 14:06, Brian S O'Neill wrote:
>> I was able to force inlining on a few key methods, and this appears to have improved performance a bit more, but inlining isn't always complete. Sometimes it gives up with messages like, "inlining too deep", "callee uses too much stack", and "don't inline Throwable constructors".
>> 
>> When inlining does work, the chain of method calls is 73, but the equivalent Unsafe chain is only 5. This might explain why Unsafe inlining usually works -- it's much shorter.
>> 
>> The inlining output will get screwed up in an email, so I pasted it here:
>> 
>> https://urldefense.com/v3/__https://gist.github.com/broneill/f1cd899ea7385acc26f23ef98070bb16__;!!ACWV5N9M2RV99hQ!MHEAnNQv3JjEMtuNRWZWKhMY1XB-PvTLJOQfXiQSkBFarqvRwUEnlM6vGiFwv5K1qmMvFspzebVf2Xu9LOZ5fQ$ 
>> One thing I find shocking is that when the method is inlined, the entire chain is processed again, every single time. There's no smaller intermediate representation being generated.
>> 
>> When inlining is partial, one of the methods it skips is "java.lang.Object::<init> (1 bytes)   failed to inline: inlining too deep".  Will this subsequently prevent escape analysis from eliminating an unnecessary allocation?
>> 
>> Inlining also fails sometimes with this message: "failed to inline: size > DesiredMethodLimit". The long method chain should ideally collapse into a single machine instruction, but if the intermediate representation is too large, is HotSpot just giving up?
>> 
>> 
>> On 2024-10-29 05:43 PM, Jorn Vernee wrote:
>>> On 29-10-2024 20:22, Brian S O'Neill wrote:
>>>> 
>>>>> 
>>>>> If you have a better benchmark, or you can pin point the exact place where the inlining failure occurs that would help immensely. You can play around with CompileCommand and force inline for specific methods of your application. (perhaps after verifying that such methods are not inlined, which you can verify with -XX:+PrintInlining).
>>>>> 
>>>> 
>>>> How do I force inlining? I thought this was only possible the internal HotSpot annotation.
>>> 
>>> 
>>> See the output of 'java -XX:CompileCommand=help' (look at the output before the standard help message). To force inlining of a method into other compilation units you would use something like `- XX:CompileCommand=inline,xyz.MyClass::myMethod`.
>>> 
>>> Jorn
>>> 
>>