Run wabt tools in Chicory

[electrum]

Modification of #337 to avoid problematic shading by splitting out tests into separate modules.

[electrum]

The flakiness mentioned in TestGenMojo seems to happen even with the retries:

Caused by: java.lang.IllegalArgumentException: Resource not found at classpath: wast2json
    at com.dylibso.chicory.runtime.Module.lambda$builder$4 (Module.java:483)
    at com.dylibso.chicory.runtime.Module$Builder.build (Module.java:532)
    at com.dylibso.chicory.wabt.Wast2Json.<clinit> (Wast2Json.java:34)
    at com.dylibso.chicory.maven.TestGenMojo$TestGenerator.generateTests (TestGenMojo.java:232)
    at com.dylibso.chicory.maven.TestGenMojo.lambda$execute$1 (TestGenMojo.java:171)

I'll investigate this later.

[electrum]

There were two problems that caused the flakiness:

• Static usage of runtime.Module, which is not safe as runtime.Module is mutable. This is something to improve in the Chicory APIs, as it would be nice to only parse a WASM module once.
• Relying on the thread context ClassLoader to load resources. When running the test generator in parallel, the context ClassLoader was sometimes wrong.

[andreaTP]

Nice 👍

[andreaTP]

Thanks for all the fixes and the further analysis @electrum , much appreciated!

There are good improvements here over my initial approach.
At the same time, on my machine this is like 2/3 times slower than using the downloaded binaries.
I start to think that we should hold a bit for those modifications and do a round of perf improvements before moving on ...

I'm happy to hear more opinions!

[electrum]

If we’re not going to merge this, then we should revert the previous commit, as Chicory is currently broken in IntelliJ.

The current performance seems acceptable for now. While worse from a relative standpoint, the absolute build time is still fast enough. I’d rather have it working in IntelliJ.

Merging this will provide some good ”low hanging fruit” for performance improvements.

[andreaTP]

As agreed, this is good to go.

[andreaTP]

Let's create a Merge commit to preserve your work, and the commits are also well defined.

Thanks for the help!

[electrum]

Thanks! I'll look at #344 as that is an obvious performance win for these module reuse cases.

BTW, with the "well defined commits" workflow, the "rebase merge" option is helpful, as it preserves the contents of the original commits while also ensuring a linear history. This is what we use for Trino and other projects.

[andreaTP]

This is what we use for Trino and other projects.

I used to do it, I switched to "merge squash" as it's a little more "beginner friendly", e.g. you don't have to ask people to rebase etc.
If you have a strong opinion about this detail, I'm not opposed, please go ahead and propose it!
Granted, I can squash my commits 🙂

[electrum]

You can choose which option to use for a specific PR when you merge it. I use both options myself, depending on the PR.

[andreaTP]

Fair, would you like to streamline this guideline with a sentence or two in Contributing ?