When booting up the JFFI native subsystem on MacOS, a bug in JFFI is causing it to always write out the stub library to tmp and load it from there. This has a huge impact on startup, due to the cost of writing out the file each time JRuby starts and because the new file defeats all OS and JVM caches.
As shown in #9686 explorations of Prism parser startup impact, the dump and load of the JFFI stub library costs over 1s of startup time on my system:
[0.244s][info][class,load] java.nio.channels.Channels$ReadableByteChannelImpl source: shared objects file (top)
[0.245s][info][class,load] java.io.FileOutputStream$1 source: shared objects file (top)
[1.986s][info][class,load] com.kenai.jffi.internal.StubLoader$CPU source: shared objects file (top)
[1.988s][info][class,load] java.lang.invoke.LambdaForm$MH/0x00000c0004044c00 source: __JVM_LookupDefineClass__
[1.988s][info][class,load] java.lang.invoke.LambdaForm$MH/0x00000c0004045000 source: __JVM_LookupDefineClass__
I suspected this might be happening and confirmed it with Codex. I'm working on a patch for JFFI now.
When booting up the JFFI native subsystem on MacOS, a bug in JFFI is causing it to always write out the stub library to tmp and load it from there. This has a huge impact on startup, due to the cost of writing out the file each time JRuby starts and because the new file defeats all OS and JVM caches.
As shown in #9686 explorations of Prism parser startup impact, the dump and load of the JFFI stub library costs over 1s of startup time on my system:
I suspected this might be happening and confirmed it with Codex. I'm working on a patch for JFFI now.