Wasm gc step1 #1097

andreaTP · 2025-11-05T18:41:55Z

Attempting to validate the changes in #1090 I ended up(again) porting most of the work(and some new) already done to this new branch.

It's not "finished" and the encoding of types might change again, but I'm convinced is a decent starting point, and it enables implementing GC opcodes.

The public API is preserved and the test coverage is increased without regressions.

The current plan is:

publish 1.6 with everything ready but those changes
merge this PR
keep doing incremental changes to support entire WasmGC
plan a release when the process is done

tombentley

I don't claim to understand Wasm GC, but I left a few shallow remarks. If there are specific bits which can/should be checked against the spec then it would be helpful to link to the relevant bits of the spec either in a code or a PR comment.

tombentley · 2025-12-15T01:26:44Z

wasm/src/main/java/com/dylibso/chicory/wasm/types/CompType.java

+    private final StructType structType;
+    private final FunctionType funcType;
+
+    private CompType(ArrayType arrayType, StructType structType, FunctionType functionType) {


comptype ::= <functype> | <structtype> | <arraytype>

Do you want to check the exclusivity as precondition?

tombentley · 2025-12-15T01:28:13Z

wasm/src/main/java/com/dylibso/chicory/wasm/types/StorageType.java

+    private final ValType valType;
+    private final PackedType packedType;
+
+    private StorageType(ValType valType, PackedType packedType) {


Again, maybe check that exactly one is null

tombentley · 2025-12-15T01:33:14Z

wasm/src/main/java/com/dylibso/chicory/wasm/types/FunctionType.java


    public boolean equals(FunctionType other) {
-        return hashCode == other.hashCode && paramsMatch(other) && returnsMatch(other);
+        // For type equivalence, we need structural comparison even when hashCodes differ


I think this means hashCode() can be inconsistent with equals(), which can be pretty unexpected if your objects leak to code that's not written with such inconsistency in mind. So I wonder if it's strictly necessary to couple the Java notion of equality to type equivalence? If not then you could avoid the WTF kind of moments that people have when HashSets don't work.

Overall this is a very fair comment, historically we are inheriting this approach from the previous work on Function References.
I think you are right and we should, eventually, move away from it, I'd give a try to address this in an upcoming PR when dealing with types canonicalization if looks acceptable.

As a remark, we don't expect people to store those in Maps and Sets.

tombentley · 2025-12-15T01:34:21Z

wasm/src/main/java/com/dylibso/chicory/wasm/types/ArrayType.java

@@ -0,0 +1,32 @@
+package com.dylibso.chicory.wasm.types;
+
+public final class ArrayType {


Other types override equals and hashCode, but not here. Is that intentional?

good catch, done 👍

tombentley · 2025-12-15T01:39:24Z

wasm/src/main/java/com/dylibso/chicory/wasm/types/TypeSection.java

        this.types = List.copyOf(types);
    }

    public FunctionType[] types() {


The fact that this returns different types than were passed to the constructor might be worthy of a comment.

fair, done 👍

tombentley · 2025-12-15T01:51:32Z

wasm/src/main/java/com/dylibso/chicory/wasm/Parser.java

+    }
+
+    private static FunctionType parseFunctionType(ByteBuffer buffer) {
+        var paramCount = (int) readVarUInt32(buffer);


What happens on int overflow?

Currently, we are not checking some of the limits in place for other runtimes.
The "real world" limit should be this:

chicory/wasm/src/main/java/com/dylibso/chicory/wasm/WasmLimits.java

Line 25 in f685086

public static final int MAX_FUNCTION_PARAMS = 1000;

Most(all?) compilers and optimizers are going to respect that limit (alternatively things won't work in the browser).
Instead of fixing this aspect in this PR I'll open a separate issue to introduce more checks.

opened #1154

tombentley · 2025-12-15T01:52:22Z

wasm/src/main/java/com/dylibso/chicory/wasm/Parser.java

-            var paramsBuilder = new ValType.Builder[paramCount];
+    private static SubType parseSubType(int id, ByteBuffer buffer) {
+        if (id == 0x50
+                || // non final typeIdx


Does the comment apply to the previous line?

(autoformatter) should be good now

tombentley · 2025-12-15T01:53:54Z

wasm/src/main/java/com/dylibso/chicory/wasm/Validator.java

-            t.returns().forEach(this::validateValueType);
+        for (var i = 0; i < module.typeSection().typeCount(); i++) {
+            var t = module.typeSection().getRecType(i);
+            // TODO: fix me!


Did you want to merge with this TODO?

The implementation in this PR barely reaches the Validator, i.e. is not complete.

When completing the Wasm GC implementation those TODO will go away naturally/organically.

tombentley · 2025-12-15T01:54:01Z

wasm/src/main/java/com/dylibso/chicory/wasm/Validator.java

+                // The following code fixes the 2 tests, but breaks many things in GC:
+                // FunctionReferencesType-equivalence.test2
+                // FunctionReferencesType-equivalence.test3
+                // TODO: seems "wrong" when using WasmGC


Did you want to merge with this TODO?

Same as before, this is a work in progress, I prefer to have a few TODOs around to easily get back to the initial thought process for now.

tombentley · 2025-12-15T01:55:10Z

wasm/src/main/java/com/dylibso/chicory/wasm/Validator.java

        }

        if (!errors.isEmpty()) {
+            errors.stream().forEach(e -> e.printStackTrace());


Was the the printing just for debugging purposes?

Good one! Leftover, removed.

andreaTP · 2025-12-15T11:25:15Z

Thanks a ton @tombentley for the review, much, much appreciated 🙏

I'm about to go on vacation but will address your comments early next year!

andreaTP · 2026-01-06T16:58:10Z

Thanks again for the review @tombentley !
I think I responded to all the comments and I'm ready for the next round 🙂

andreaTP requested review from chirino and evacchi November 5, 2025 18:41

andreaTP mentioned this pull request Nov 5, 2025

resolve ValTypes after TypeSection is formed #1090

Closed

andreaTP force-pushed the wasm-gc-step1 branch from 2fd30c9 to 6bc98b5 Compare November 6, 2025 17:32

tombentley reviewed Dec 15, 2025

View reviewed changes

andreaTP added 9 commits January 6, 2026 15:24

resolve ValTypes after TypeSection is formed

3d80107

wasm gc: rec types parsing

93eb5ab

adding more tests

49f47bc

moving on

d9fa8b2

using hashCode as canonicalized representation

c0aea85

tight-up

2549afa

make java 25 happy

9aae0f6

make Java 21 happy again

41b86e9

review

a6660bd

andreaTP force-pushed the wasm-gc-step1 branch from 6bc98b5 to a6660bd Compare January 6, 2026 16:57

		@@ -0,0 +1,32 @@
		package com.dylibso.chicory.wasm.types;

		public final class ArrayType {

Wasm gc step1 #1097

Are you sure you want to change the base?

Wasm gc step1 #1097

Uh oh!

Conversation

andreaTP commented Nov 5, 2025

Uh oh!

tombentley left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andreaTP commented Dec 15, 2025

Uh oh!

andreaTP commented Jan 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants