Bump chasm from 1.6.1 to 1.7.0

[dependabot]

Bumps chasm from 1.6.1 to 1.7.0.
Updates io.github.charlietap.chasm:chasm-jvm from 1.6.1 to 1.7.0

Release notes

Sourced from io.github.charlietap.chasm:chasm-jvm's releases.

1.7.0

Whats Changed

GC 2.0

Chasms original solution to Wasms GC proposal was more of a simulation of a garbage collector than the real thing, it could trace roots and collect and functionally it was fine, but it performance wasn't great.

This has been replaced with a synchronous, frankly still simple, non moving mark and sweep heap. There's no generations or nurseries or anything like that but the system is robust and it does its job very well. High level it stores ordinary objects in pages backed by primitive arrays, records which fields contain references, and reuses reclaimed slots and pages. GC instructions now allocate and access values directly through this heap without creating temporary Kotlin objects or payload arrays.

Against Chasm 1.6.1, four-field struct allocation improved from 7.263 ns to 4.076 ns, while 32-field allocation improved from 14.892 ns to 6.318 ns. Random field reads improved from 1.734 ns to 0.591 ns and writes from 1.758 ns to 0.685 ns.

The previous representation allocated 72 bytes per four-field struct and 296 bytes per 32-field struct. The new ordinary allocation path is effectively allocation-free after warmup.

Collecting 100,000 unreachable objects improved from 1.099 ms to 0.096 ms. Collecting 100,000 live objects improved from 3.467 ms to 0.752 ms.

For workloads that include GC instructions you should expect to see a small performance bump, if the workload is long running or memory intensive enough to trigger collection you should expect a much larger performance bump. Bare in mind the GCThreshold in Chasms config is set to 8MB by default and most workloads I've seen fall short of this and therefore never trigger collection, which is really where the performance gains are to be had.

Commits

• 3a8af42 release: prepare for release 1.7.0
• 39da78f corpus: establish baseline for new GC implementation
• c31c71a abi: fix newline issue in API
• 0ce50c4 gc: introduce real garbage collector and rework existing gc instructions to l...
• 1506324 embedding: prevent use of imports from another store during instantiation
• 392820e embedding: prevent use of dropInstance with an incorrect store
• See full diff in compare view

Updates io.github.charlietap.chasm:chasm from 1.6.1 to 1.7.0

Release notes

Sourced from io.github.charlietap.chasm:chasm's releases.

1.7.0

Whats Changed

GC 2.0

Chasms original solution to Wasms GC proposal was more of a simulation of a garbage collector than the real thing, it could trace roots and collect and functionally it was fine, but it performance wasn't great.

This has been replaced with a synchronous, frankly still simple, non moving mark and sweep heap. There's no generations or nurseries or anything like that but the system is robust and it does its job very well. High level it stores ordinary objects in pages backed by primitive arrays, records which fields contain references, and reuses reclaimed slots and pages. GC instructions now allocate and access values directly through this heap without creating temporary Kotlin objects or payload arrays.

Against Chasm 1.6.1, four-field struct allocation improved from 7.263 ns to 4.076 ns, while 32-field allocation improved from 14.892 ns to 6.318 ns. Random field reads improved from 1.734 ns to 0.591 ns and writes from 1.758 ns to 0.685 ns.

The previous representation allocated 72 bytes per four-field struct and 296 bytes per 32-field struct. The new ordinary allocation path is effectively allocation-free after warmup.

Collecting 100,000 unreachable objects improved from 1.099 ms to 0.096 ms. Collecting 100,000 live objects improved from 3.467 ms to 0.752 ms.

For workloads that include GC instructions you should expect to see a small performance bump, if the workload is long running or memory intensive enough to trigger collection you should expect a much larger performance bump. Bare in mind the GCThreshold in Chasms config is set to 8MB by default and most workloads I've seen fall short of this and therefore never trigger collection, which is really where the performance gains are to be had.

Commits

• 3a8af42 release: prepare for release 1.7.0
• 39da78f corpus: establish baseline for new GC implementation
• c31c71a abi: fix newline issue in API
• 0ce50c4 gc: introduce real garbage collector and rework existing gc instructions to l...
• 1506324 embedding: prevent use of imports from another store during instantiation
• 392820e embedding: prevent use of dropInstance with an incorrect store
• See full diff in compare view