[vm/ffi] Investigate outlining state transitions in AOT

[dcharkes]

JIT x64

out/ReleaseX64/dart --disassemble --disassemble-relative --print-flow-graph-filter=FfiTrampoline_Handlex01 benchmarks/FfiCall/dart/FfiCall.dart Handle

FfiTrampoline_Handlex01: 0x131 = 305 bytes

JIT uses a stub to transition from generated code to native going into a safepoint.

AOT x64

dart pkg/vm/bin/gen_kernel.dart --aot --platform=out/ReleaseX64/vm_platform_strong.dill -o benchmarks/FfiCall/dart/FfiCall.dill benchmarks/FfiCall/dart/FfiCall.dart && out/ReleaseX64/gen_snapshot --disassemble --disassemble-relative --print-flow-graph-filter=FfiTrampoline_Handlex01 --snapshot-kind=app-aot-assembly --assembly=benchmarks/FfiCall/dart/FfiCall.asm benchmarks/FfiCall/dart/FfiCall.dill

FfiTrampoline_Handlex01: 0x1b3 = 435 bytes

AOT doesn’t use a stub to go transition into native + safepoint.
This means all the transition code is inline, adding ~130 bytes. (There are some minor other differences as well.)

We consider checking what the speed penalty is for using a stub in AOT.

[dcharkes]

Always outlining the transitions in FFI trampolines

• reduces trampoline size significantly (up to 50%, 150-170 bytes),
• regresses performance on arm64 and x64 minimally (up to 2.5% and 3.5% respectively), and
• regresses performance on arm significantly (up to 26%).

I propose to outline on arm64 AOT as we care about size there.
I propose to keep x64 AOT as is, because we care less about binary size for desktops/laptops.

I'm not entirely sure what to think of arm. We care about size, but I'm not sure how many trampolines we have in a Flutter app and how often we call them.

Internal doc with all measurements.

cc @mkustermann @mraleph.