Add Box2D workload compiled with J2CL/J2Wasm to WasmGC

[danleh]

Right now, it requires an additional entrypoint in the upstream j2cl benchmark to avoid explicit warmup and perform a constant amount of work (see add-fixed-run-count-api.patch).

Since JSC seems to not implement JS-string builtins yet, I also added a workaround (they never get called in this workload anyway), which we can hopefully remove later. @kmiller68

[netlify]

✅ Deploy Preview for webkit-jetstream-preview ready!

Name	Link
🔨 Latest commit	70cbdcb
🔍 Latest deploy log	https://app.netlify.com/projects/webkit-jetstream-preview/deploys/68bff641fefce5000887380e
😎 Deploy Preview	https://deploy-preview-130--webkit-jetstream-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[danleh]

Any comments from Mozilla's side @eqrion and @iainireland?
(Sidenote: I cannot add them as reviewers, unlike you @kmiller68 or Camillo. Could they be missing some permissions / contributor status here?)

[eqrion]

I'm not seeing names in any of the functions, or a name map checked in along with the benchmark. Could you compile to include the name section? That makes analysing things much easier.

Also, would you be open to naming this j2cl-box2d-wasm? Having wasm in the title makes it easy for us to filter tests in CI, which can only use the title of tests.

[danleh]

Renaming the workloads sounds fine. Regarding function names, I need to fiddle a bit with the Bazel build config, since I don't want to measure a debug build.

[danleh]

Turns out, there already is a .symbolmap file available in the j2cl output directory, I just copied that over to build/ now. (As in the other workloads, there is no name section in the binary, but I suppose this off-the-side debug info is good enough for analysis/debugging and this way we actually measure the release binary).

[kmiller68]

Seems to spend almost half the time in m_solveVelocityConstraints__void (~35%) and m_run__java_lang_Object (~10%) in both Chrome and Safari. Firefox is a bit more even with ~10% for each but the profiler there seemed to induce a lot of overhead (5x) so idk how much to trust the results.

This isn't necessarily a dealbreaker but I'm not sure this will measure J2Wasm as much as these two functions, which is probably less interesting to benchmark. Happy to land disabled for now while we discuss though.

[kmiller68]

@danleh Have you looked at the wasm for those functions? Do you know if there's anything interesting about them that would be worth optimizing in anger?

[danleh]

Recording our discussion from last week: I would still like to merge this, since it gives us coverage of yet another Wasm toolchain (j2cl/j2wasm) that is used in a widely deployed web application, has been a good workload to catch regressions in v8 in the past according to j2cl folks and our own experience, and according to @eqrion @iainireland is not incentivizing any problematic optimizations.

One concern was that we might be having a too high proportion of Wasm workloads, but that should be alleviated by disabling more of the clearly outdated ones in #178. When we merge (at least some) of the new JS workloads, this proportion will go down further as well.

I had a look at a x64 CPU profile in d8 as well, and that seems to be not too centered along a single function, see the attached screenshot.

For reference, function 167 corresponds to m_solveVelocityConstraints__void, 241 to m_run__java_lang_Object, 151 to m_findNewContacts__void, 116 to m_insertLeaf__int__void_, 98 to m_findMaxSeparation__org_..., and 29 to m_mergeSort__arrayOf_.... The source for solveVelocityConstraints is quite complex (in the jbox2d library), and it generates quite a bit of Wasm bytecode including struct field accesses and math operations, so I think it is interesting indeed.

@kmiller68 @eqrion How about merging this and tuning or discussing specifics in follow-up PRs?

[eqrion]

Merging is good with me. As I said before, we haven't seen anything outrageous about the wasm code here, and it's better than some of the previous wasm benchmarks we've had. Although, obviously not perfect either.

[kmiller68]

Seems good to me too. Happy to revisit if anything interesting comes up.