Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Redline: trampolines must be precomputed at build time; the Cranelift bridge must not be a runtime dependency

Open
  • Is something wrong?
#202 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Active
Tech stack
java, wasm
Domain
backend, build-system

Research direction

Trace JffiNativeMachine, the Panama NativeMachine, CraneliftBridge, and NativeCodeSerializer to map where trampolines are compiled and serialized. Start by comparing constructor-time compilation with the .native payload and runner dependencies. Done means all listed trampoline sets are available from build-time output, instance-specific addresses are handled by indirection or relocations, and both runner modules no longer require the bridge at runtime.

Written by the indexing model from the issue text.

Description

Both native machines (JffiNativeMachine and the Panama NativeMachine) compile their ABI trampolines in the constructor, i.e. once per instance:

try (var bridge = new CraneliftBridge()) {   // Instance.builder(Cranelift.load())...build()
    bridge.init(RedlineTarget.detectHost()...triple());
    var trampolines = bridge.compileTrampolines(compiledCode, funcTypesByBody, importTypes, importStubAddrs, ...);

CraneliftBridge() instantiates the Cranelift compiler (the 2.5 MB cranelift_bridge.wasm, on the bytecode compiler) every time. The build-time output (NativeCodeSerializer) only contains the function bodies, no trampolines. Measured with quickjs4j (Endive 1.1.0, javy module): 0.8–2.9 s and ~+26 MB RSS per Instance, versus ~0.1 s for the build-time compiled bytecode. Anything that creates instances regularly (camel-quickjs recycles an engine every few thousand evaluations) is dominated by this.

Expected design: everything is precomputed at build time. The runners only load and link, and redline-bridge-experimental (the Cranelift compiler) must not be a runtime dependency of redline-runner-experimental / redline-runner-jffi-experimental at all; today both declare it in compile scope.

Concretely:

  • the build-time compiler emits the entry trampolines, import trampolines, internal stub trampolines and memmove/memset trampolines next to the function bodies (one set per target), in the .native payload;
  • the per-instance addresses they embed today (import closure stubs, watchdog/memgrow stubs, memmove/memset) are either read indirectly from the ctx buffer / function table, so the trampolines are position-independent, or patched at load time through a small relocation table in the payload;
  • the runners drop the dependency on the bridge; the bridge stays a build-time-only artifact.

🤖 Generated with Claude Code

Dominant language
Java
Stars
306
Forks
20
Avg merge
1d 19h
Merged PRs (30d)
35

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bytecodealliance/endive

All issues in bytecodealliance/endive

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.