WasmGC Deep Dive [2026]: Java and Kotlin in Browsers

For most of WebAssembly's first decade, garbage-collected languages reached the browser by dragging a miniature VM and memory manager behind them. WasmGC changes that design completely. With browser engines now shipping the feature by default, Java and Kotlin toolchains can map objects onto VM-managed references instead of emulating heaps in linear memory, which is why April 2026 finally feels like the moment this stops being a lab exercise and starts looking like a serious application architecture.

• Browser support is no longer hypothetical: Chrome 119, Firefox 120, and Safari 18.2 all satisfy Kotlin's current baseline.
• WasmGC lets toolchains emit typed structs and arrays instead of building a language heap inside linear memory.
• V8 reports an average 1.9x Java speedup from wasm-opt on Box2D, DeltaBlue, RayTrace, and Richards.
• Kotlin 2.3.20 adds up to 4.6x faster string interpolation in targeted Wasm benchmarks, plus about 5% smaller binaries in the KotlinConf app build.

The Lead

The important shift is not that browsers learned a new file format. They learned enough about managed objects to stop treating Java and Kotlin as second-class citizens. That changes code generation, GC behavior, interop semantics, and even the kind of debugging and performance work that becomes possible.

What changed between the first Wasm era and now

• The original WasmMVP model was excellent for C, C++, and Rust, but clumsy for languages with automatic memory management.
• WasmGC introduces GC-aware types and operations so compilers can represent objects directly in Wasm.
• Browser support crossed the practical threshold, which matters more than spec enthusiasm for production teams.
• Toolchains now have enough optimization infrastructure to make the new target competitive rather than merely possible.

That last point is the one many teams miss. A feature can be standardized and still be strategically irrelevant if compilers and engines cannot exploit it. The reason the conversation changed in 2025 and 2026 is that engine work, compiler work, and browser rollout finally lined up.

Architecture & Implementation

What WasmGC actually adds

At the runtime level, the headline capability is straightforward: Wasm modules can define typed struct and array objects that are managed by the host VM's garbage collector. That matters because a Java or Kotlin object graph can stop pretending to be a manually managed byte range.

• References on the call stack no longer require a shadow-stack workaround just to stay visible to the collector.
• Cross-boundary object graphs are more natural, which improves JavaScript interoperability and cycle collection.
• Memory fragmentation pressure drops because object lifetimes are handled by a moving, VM-aware collector instead of allocator patterns inside linear memory.
• The browser can make GC decisions with global knowledge about memory pressure and scheduling.

V8's own write-up frames the change as a shift from porting a language runtime to a new architecture toward porting a language into an existing VM. That is the right mental model. Instead of embedding a garbage-collected world inside Wasm, the compiler speaks the browser's managed-object dialect directly.

What Kotlin and Java toolchains emit

On the Kotlin side, the most concrete production-facing target is Kotlin/Wasm. JetBrains still labels it Beta, but the model is already clear: browser apps use the wasmJs target, and server-side or standalone runtimes use wasmWasi. Kotlin's current docs also make one compatibility rule explicit: browser deployments need support for WasmGC and legacy exception handling.

On the Java side, the story is more split.

• TeaVM is the practical path if you want Java bytecode compiled ahead-of-time to browser-ready JavaScript or WebAssembly today.
• J2Wasm is strategically important because V8 uses it to demonstrate what a more direct Java-to-WasmGC pipeline can achieve.
• That means the strongest public performance evidence is coming from the more experimental side, while the most usable delivery path today is the more mature compiler ecosystem around TeaVM.

A minimal Java entry point using the official TeaVM 0.12.3 archetype looks like this:

mvn -DarchetypeCatalog=local \
  -DarchetypeGroupId=org.teavm \
  -DarchetypeArtifactId=teavm-maven-webapp-wasm-gc \
  -DarchetypeVersion=0.12.3 archetype:generate

On the Kotlin side, compiler switches still matter, especially where exception proposal support differs by runtime:

kotlin {
  wasmJs {
    compilerOptions {
      freeCompilerArgs.add("-Xwasm-use-new-exception-proposal")
    }
  }
}

If you are reading generated wrappers or exported glue around these boundaries, the internal structure gets dense quickly. This is one of those cases where TechBytes' Code Formatter is actually useful as an engineering aid, not just a convenience, because browser-facing Wasm interop layers are easier to reason about once imports, exports, and trampolines are normalized.

Why post-lowering optimization matters so much

The V8 team makes a crucial toolchain argument: once a language has lowered into WasmGC, a shared Wasm-to-Wasm optimizer can do meaningful whole-program work that benefits multiple languages. In practice that means Binaryen and wasm-opt become central pieces of the architecture.

• Escape analysis can move some heap allocations into locals.
• Devirtualization can turn indirect calls into direct ones that later inline cleanly.
• Type-aware global dead code elimination becomes more effective because the optimizer sees managed object structure.
• Cast pruning, type merging, and type refining help reduce both size and dispatch overhead.

This is one of the most important strategic advantages of WasmGC: the optimization surface becomes more shared across languages instead of forcing every toolchain to reinvent the same mid-end logic.

Benchmarks & Metrics

The best public numbers right now come from two places: V8's Java experiments and JetBrains' Kotlin release notes. They measure different layers of the stack, but together they show why this target is moving from interesting to investable.

Java numbers that matter

• V8 reports that wasm-opt makes J2Wasm output an average of 1.9x faster across Box2D, DeltaBlue, RayTrace, and Richards.
• In Google's Sheets Calc Engine, V8 says speculative inlining alone delivered about a 30% speedup.
• The implication is architectural, not cosmetic: once the VM understands the object model, classic managed-language optimizations start paying off again.

That last point matters more than the absolute numbers. Many teams still evaluate browser Wasm as if the only question is raw execution speed versus JavaScript. The more important question is whether a managed-language compiler can hand enough structure to the engine for the engine to optimize like a real VM rather than a sandboxed byte buffer executor. These numbers suggest the answer is increasingly yes.

Kotlin metrics that matter

• Kotlin/Wasm remains Beta, which is a maturity caveat you should treat seriously.
• Kotlin 2.3.20 reports up to 4.6x faster string interpolation in targeted benchmarks.
• The same release reports about 5% smaller Wasm binaries for the KotlinConf application build.
• JetBrains also reports around a 1% median improvement across all Wasm benchmarks and at least 20% faster append-heavy string workloads.

How to interpret the benchmark story

Do not read the Java and Kotlin results as apples-to-apples proof that one language wins. Read them as evidence that WasmGC changes the performance model itself. Java shows how much engine-level optimization still exists above the compiler. Kotlin shows how fast the language toolchain is improving once the target stops fighting the runtime model. Together they point to the same conclusion: the browser is becoming a more legitimate host for managed languages, not just a fallback environment.

Strategic Impact

Where this changes system design

• Cross-platform teams can share more business logic without forcing everything through JavaScript-first abstractions.
• Compose Multiplatform gets a more credible browser backend because UI and state no longer sit on top of such an awkward memory emulation story.
• Long-lived, object-heavy applications such as editors, financial tooling, and domain-rich enterprise frontends become more plausible candidates.
• Optimization work can move down into shared Wasm infrastructure instead of living only in language-specific compilers.

There is also a staffing angle here. Teams with deep JVM and Kotlin expertise can now consider the browser as an extension of existing engineering capability rather than a full ecosystem reset. That does not eliminate JavaScript from the picture, but it changes how much of the application truly has to be rewritten for the web.

When to choose which path

Choose WasmGC when:

• Your codebase is object-heavy and would otherwise pay a large runtime tax to emulate managed memory.
• You want tighter JS interop and fewer architectural hacks around object lifetime and cycles.
• You are investing in medium-term platform leverage, not just shipping the quickest browser port possible.
• You can require modern browser versions in production.

Choose a traditional WasmMVP port when:

• You need maximum browser reach, including older environments.
• You already have a mature existing runtime whose semantics would be expensive to remap.
• Your application is compute-heavy but not particularly object-model-heavy.
• Your delivery risk tolerance is low and ecosystem maturity matters more than architectural elegance.

Road Ahead

The next two years are less about proving that WasmGC works and more about deciding where it becomes the default. The open questions now sit in tooling, debuggability, packaging, and ecosystem confidence.

• Kotlin/Wasm still needs to graduate from Beta for many conservative teams to treat it as a default frontend target.
• Java needs a cleaner story that combines production ergonomics with the optimization headroom demonstrated by J2Wasm and V8.
• Library compatibility remains uneven, especially for frameworks and reflection-heavy code.
• Proposal churn is lower than before, but features such as exception handling variants and evolving interop patterns still matter in deployment policy.

Still, the strategic direction is unusually clear. WasmGC does for browser-hosted managed languages what the original Wasm launch did for systems languages: it removes a structural mismatch that had distorted both performance and architecture. The browser will not become the JVM, and Kotlin/Wasm will not replace every JavaScript stack. But the old assumption that Java and Kotlin must fight the browser's runtime model is no longer true, and that is a much bigger change than another benchmark headline.

Primary references worth keeping open while evaluating the stack: the Kotlin/Wasm overview, Kotlin's supported versions and browser matrix, Chrome's WasmGC explainer, V8's implementation deep dive, and the official TeaVM getting started guide.