Skip to content

JFFI bad library load is a huge startup hit on MacOS #9690

Closed

Description

@headius

Clone of #9688 for 10.1.

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.

Activity

  1. added this to the JRuby 10.1.2.0 milestone on Sep 15, 2026
  2. headius commented on Sep 16, 2026

    @headius
    MemberAuthor

    Fixed by JFFI update from #9689 merged from 10.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions