Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Runtime compiler retains excessive memory

Aperta
  • Qualcosa non va?
#249 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@andreas-karlsson ci sta già lavorando.

Dal 23/10/2026.

  • #251 di @andreas-karlsson — chiusa senza merge
  • #252 di @andreas-karlsson — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java, wasm
Ambito
backend, performance

Direzione di ricerca

Start by tracing how MachineFactoryCompiler, Instance, and MachineFactory retain the WasmModule, then identify how compiled and interpreted functions use their bodies. Compare the three approaches in the issue, including their effects on module fidelity and identity checks. Done means selecting and implementing a memory reduction approach while preserving the required runtime behavior; the issue does not name files or tests.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

A module compiled with MachineFactoryCompiler retains the full WasmModule at runtime (via Instance and MachineFactory). Contractually it needs to do this since Instance has a WasmModule getter, but only interpreted functions actually need the body definitions. For our use case, a server that reads Wasm modules on the fly from cloud storage and deploys them, this "dead code" amounts to ~5 GB, about 70% of our retained heap. The problem is exacerbated by every Wasm instruction being represented by an AnnotatedInstruction, which retains about 70 bytes per instruction (compared to Wasm's native 1–2 bytes).

If agreed that this is a problem that needs fixing, I see a few ways forward (in my order of perference):

  • Only retain the original Wasm binary for compiled functions, and let WasmModule parse them lazily (with weak memoization). This keeps a faithful representation, and my back-of-napkin calculation suggests a ~30x reduction in memory retained by function bodies (~70 bytes per parsed instruction vs. 1–2 bytes of binary).
  • Add a builder option like withDiscardCompiledFunctionBodies which retains a stripped WasmModule, keeping only bodies of interpreted functions (and their tail-call targets). Accessing a stripped function throws IllegalStateException. The downside is that Instance#module() is no longer a faithful representation.
  • Or as a lower-level escape hatch: let the compile result expose which function bodies the interpreter needs (interpreted functions and their tail-call targets), stop MachineFactory from holding on to the module, and relax its module identity check (e.g. to a digest check). Users could then pass their own stripped module to Instance.builder(module).withMachineFactory(factory) and own the trade-off themselves.
Lingua principale
Java
Stelle
315
Fork
24
Merge medio
1g 3m
PR unite (30g)
29

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bytecodealliance/endive

Tutte le issue di bytecodealliance/endive

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.