FFM performance tweaks

[Maurizio Cimadamore]

Thanks for confirming.

Maybe it's a dead end, although the dependency on 
-XXStressIncrementalInline kind of make sense, given we had 
independently verified that a large number of dead nodes were present in 
the compiled graph, and those nodes contributed to the overall "count". 
So, in effect, by enabling that option, we make more methods target for 
incremental inlining, which is independent of dead nodes, which then 
solves the specific issue with NodeCountInliningCutOff (at least that's 
my understanding).

Maurizio

On 22/11/2024 18:47, Brian S O'Neill wrote:
> I tested with the -XX:+StressIncrementalInlining option and it tends 
> to slow down the warmup period, but overall performance isn't 
> improved. In one case it appeared to be about 5% slower overall.
>
> On 2024-11-22 10:03 AM, Maurizio Cimadamore wrote:
>
>>>
>>> Having no other (obvious) way to affect inlining in a product JVM, one
>>> workaround that did work was -XX:+StressIncrementalInlining (with some
>>> variance due to randomization of should_delay_inlining()). Not sure why
>>> this is a product flag, but it does make a huge difference. Everything
>>> in demo_draw_build_cmd gets fully inlined and GC activity drops to
>>> nothing, with either the JNI or FFM backends.
>> This is an intersting finding! I'd be curious if this could also be 
>> replicated in Brian's tuple database benchmark.
>>>