Implement Wasm WASI target and fork mode for WasmJs with custom engines by igoriakovlev · Pull Request #361 · Kotlin/kotlinx-benchmark

igoriakovlev · 2026-03-31T14:56:23Z

Here we have several major changes:
First of all I have removed d8 support from gradle plugin (it was needed for internal use only)
Second I have added Wasm WASI target (runned with nodejs)
Third implement wasmFork = perBenchmark. User can use it as in other targets, like in Native.
Fourth - support WasmJs custom engines - it supposed to be used internally.
Fifth - as we now have now custom engines I remove internal d8 engine support from the Runtime.

(fixed 287)

fzhinkin · 2026-04-02T18:39:37Z

plugin/main/src/kotlinx/benchmark/gradle/Utils.kt

            }

-            else -> throw IllegalArgumentException("Invalid advanced option name: '$param'. Accepted options: \"nativeFork\", \"nativeGCAfterIteration\", \"jvmForks\", \"jsUseBridge\".")
+            "wasmFork" -> require(value is String) {


Please validate the value of the option like for the nativeFork

runtime/commonMain/src/kotlinx/benchmark/RunnerConfiguration.kt

fzhinkin · 2026-04-02T18:59:58Z

plugin/main/src/kotlinx/benchmark/gradle/JsEngineExecTasks.kt

            if (compilationTarget.isNodejsConfigured) {
-                val execTask = createNodeJsExec(config, target, compilation, taskName)
-                tasks.getByName(config.prefixName(RUN_BENCHMARKS_TASKNAME)).dependsOn(execTask)
+                val execTask = createNodeJsExec(config, target, binary.compilation,  executableFile, taskName)


Please add the dependency on the link task:

execTask.configure { it.dependsOn(binary.linkTask) }

It's one of those warning our tests were printing in CI

fzhinkin · 2026-04-02T18:59:59Z

plugin/main/src/kotlinx/benchmark/gradle/JsEngineExecTasks.kt

            if (compilationTarget.isNodejsConfigured) {
-                val execTask = createNodeJsExec(config, target, compilation, taskName)
-                tasks.getByName(config.prefixName(RUN_BENCHMARKS_TASKNAME)).dependsOn(execTask)
+                val execTask = createNodeJsExec(config, target, binary.compilation,  executableFile, taskName)


Please add the dependency on the link task:

execTask.configure { it.dependsOn(binary.linkTask) }

It's one of those warning our tests were printing in CI

plugin/main/src/kotlinx/benchmark/gradle/Utils.kt

runtime/wasmJsMain/src/kotlinx/benchmark/wasm/WasmPerProcessExecutors.kt

fzhinkin · 2026-04-02T19:47:51Z

plugin/main/src/kotlinx/benchmark/gradle/BenchmarkConfiguration.kt

 import kotlin.text.replaceFirstChar

+@KotlinxBenchmarkPluginInternalApi
+data class CustomEngine(val name: String, val enginePath: Provider<RegularFile>, val engineArguments: Provider<String>)


Is it really internal? If so, it should not be exposed via BenchmarkConfiguration.

Also, please make it a regular class, not a data class.

Alternative option: keep the class private, add a function customJsEngine(...) that will pack all the arguments to advanced. Also, it seems crucial to explicitly specify that the engine is the Js/WasmJs/WasmWasi engine. Maybe, the runtime or VM would be a better name?

It is internal because not intended to used by the user. Could you please to
reveal an idea about this function customJsEngine? Where it should be placed, with which visibility? Any opt-ins? Etc. Thank you.

fzhinkin · 2026-04-02T19:48:36Z

plugin/main/src/kotlinx/benchmark/gradle/BenchmarkConfiguration.kt

 import kotlin.text.replaceFirstChar

+@KotlinxBenchmarkPluginInternalApi
+data class CustomEngine(val name: String, val enginePath: Provider<RegularFile>, val engineArguments: Provider<String>)


Why engineArguments are string, and not a list of strings?

Well. It is not very handy to have a list when you deal with Providers. Should it be a provider if list? or list of providers? or list of providers of strings? :)
For us (in wasm) to have this function the best way to express our needs is just a provider of string, But if you have a better idea from library point of view i would love to implement it.

Will make it with Provider

plugin/main/src/kotlinx/benchmark/gradle/BenchmarkConfiguration.kt

plugin/main/src/kotlinx/benchmark/gradle/JsMultiplatformTasks.kt

fzhinkin

There are a few questions popped up during the last review round, but otherwise I'm OK with current implementation given that it is effectively non-public.

fzhinkin · 2026-04-10T18:42:06Z

runtime/commonMain/src/kotlinx/benchmark/RunAllBenchmarksExtension.kt

+import kotlinx.benchmark.internal.KotlinxBenchmarkRuntimeInternalApi
+
+/**
+ * Runs a complete benchmark suite by iterating over all configured benchmarks and their parameter combinations.


If it runs the whole suite, then what's the difference with SuiteExecutor? Should they be a single class / interface? Is there any relation between them?

fzhinkin · 2026-04-10T18:44:51Z

runtime/commonMain/src/kotlinx/benchmark/RunAllBenchmarksExtension.kt

+ * - [runBenchmark] should return raw sample values in nanoseconds, or `null` if the benchmark produced no result
+ * - [saveBenchmarkResults] converts raw samples, records the formatted result, and notifies [reporter]
+ */
+@KotlinxBenchmarkRuntimeInternalApi


Can we make the interface internal instead? After you introduced KotilnxBenchmarkRuntimeExperimentalApi annotation, can everything that is still annotated with KotlinxBenchmarkRuntimeInternalApi be converted into internal?

fzhinkin · 2026-04-10T18:46:09Z

runtime/commonMain/src/kotlinx/benchmark/RunAllBenchmarksExtension.kt

+ * - [saveBenchmarkResults] converts raw samples, records the formatted result, and notifies [reporter]
+ */
+@KotlinxBenchmarkRuntimeInternalApi
+interface RunAllBenchmarksExtension {


Where the Extension comes from? Here, and in CommonBenchmarkExtension. Why the latter can not remain CommonBenchmarkExecutor and this interface be SuiteExecutor?

fzhinkin · 2026-04-10T18:47:29Z

runtime/jsWasmJsSharedMain/src/kotlinx/benchmark/EngineSupport.kt

+package kotlinx.benchmark
+
+@KotlinxBenchmarkRuntimeExperimentalApi
+abstract class Measurer {


Please add some doc describing how Measurer, BenchmarkEngineSupport and overrideEngineSupport are related, why are they needed and how to implement them.

igoriakovlev requested a review from fzhinkin April 1, 2026 13:07

igoriakovlev force-pushed the yakovlev/wasm_fork_support branch 2 times, most recently from 8576f98 to c07a932 Compare April 1, 2026 15:01

fzhinkin requested changes Apr 2, 2026

View reviewed changes

igoriakovlev force-pushed the yakovlev/wasm_fork_support branch from 6dc4298 to 3413d05 Compare April 9, 2026 15:56

igoriakovlev added 3 commits April 9, 2026 18:08

Commonize common executor for Wasm and Js targets

dfee39e

Plugins support for wasm and js engines

5462673

Remove d8 runner support

6cc49f4

igoriakovlev force-pushed the yakovlev/wasm_fork_support branch 3 times, most recently from e7ef665 to bb3b759 Compare April 9, 2026 17:54

igoriakovlev added 5 commits April 10, 2026 16:37

Support engine forks

f56c9f2

Implement Wasm WASI target

059e422

Add built type to kotlin js and kotlin wasm property benchmark target

b18b5e3

Update plugin API dump

3166c38

Fix tests and add custom engine test

675d01d

igoriakovlev force-pushed the yakovlev/wasm_fork_support branch from bb3b759 to 675d01d Compare April 10, 2026 14:38

fzhinkin requested changes Apr 10, 2026

View reviewed changes

Conversation

igoriakovlev commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

Uh oh!

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!

igoriakovlev Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

fzhinkin 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

igoriakovlev commented Mar 31, 2026 •

edited

Loading

igoriakovlev Apr 7, 2026 •

edited

Loading