Deliverable: short report of compatibility gaps and a minimal Wasm GC "hello world" module.
Browser GC is not directly controllable, but Eaglercraft 1.12:
Java bytecode (Minecraft 1.12 + mods)
↓
[TeaVM / WASM compiler with GC integration]
↓
WASM module using GC
↓
Browser (Chrome, Firefox, Edge) with WASM GC support
No technology is magic. WASM GC is new, and Eaglercraft 1.12 WASM GC has edge cases: eaglercraft 112 wasm gc
| Aspect | Without WASM GC | With WASM GC (Eaglercraft 1.12) | |--------|----------------|--------------------------------| | Memory usage | High (JS heap + WASM linear memory) | Lower (unified browser GC) | | GC pauses | Frequent, long | Browser-optimized, shorter | | Mod compatibility | Low (no reflection/GC interop) | Higher (supports more Java patterns) | | Binary size | Large (includes GC runtime) | Smaller (uses browser’s GC) | | FPS in 1.12 | 10–30 | 30–60+ (on modern machines) |
WASM GC is still a proposal (phase 4, nearing standardization). Eaglercraft 1.12 includes: Deliverable: short report of compatibility gaps and a
Support table (as of 2026):
| Browser | WASM GC | Eaglercraft 1.12 mode | |---------|---------|------------------------| | Chrome 119+ | ✅ | Modern (fast) | | Firefox 120+ | ✅ | Modern | | Safari 17.4+ | ✅ (behind flag) | Modern with polyfill | | Edge 119+ | ✅ | Modern | No technology is magic
Older versions of Eaglercraft (e.g., 1.8) used:
The core problem: Java’s implicit memory allocation becomes unpredictable when translated to JS, leading to GC churn and frame drops.
Deliverable: consistent frame-rate improvements and measurable reductions in JS-Wasm crossing.