You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using the @swc/plugin-formatjs plugin as part of our internationalization system.
Our build system (Bazel + aspect_rules_swc) spawns many, many SWC processes concurrently. Under most circumstances this works great! SWC starts up so fast.
We're currently seeing two different issues related to the WASM bytecode cache.
Issue 1)
SWC won't use the bytecode cache if the directory is read only.
aspect_rules_swc tries to pre-populate the bytecode cache and pass it as as an explicit input to SWC actions. Unfortunately the build system marks this directory as read-only when it's used as an input. From what I can tell SWC is using wasmer's FileSystemCache (here), which fails if the directory is read only (here) and falls back to an in-memory cache every time (which doesn't help us when we're spawning many small, granular actions). The net effect is that we re-prepare the plugin bytecode many thousands of times. The cache is pre-populated, so we know that it won't be written to. It would be nice in this scenario if the cache failed on write instead of failing to initialize altogether.
We've tried to mitigate this by setting jsc.experimental.cacheRoot to a writable dirctory outside of the build system's control (e.g. /tmp/swc) but…
Issue 2)
SWC fails intermittently when multiple processes try to write to the SWC cache at the same time.
Describe the bug
Context
We're using the
@swc/plugin-formatjs
plugin as part of our internationalization system.Our build system (Bazel +
aspect_rules_swc
) spawns many, many SWC processes concurrently. Under most circumstances this works great! SWC starts up so fast.We're currently seeing two different issues related to the WASM bytecode cache.
Issue 1)
SWC won't use the bytecode cache if the directory is read only.
aspect_rules_swc
tries to pre-populate the bytecode cache and pass it as as an explicit input to SWC actions. Unfortunately the build system marks this directory as read-only when it's used as an input. From what I can tell SWC is usingwasmer
'sFileSystemCache
(here), which fails if the directory is read only (here) and falls back to an in-memory cache every time (which doesn't help us when we're spawning many small, granular actions). The net effect is that we re-prepare the plugin bytecode many thousands of times. The cache is pre-populated, so we know that it won't be written to. It would be nice in this scenario if the cache failed on write instead of failing to initialize altogether.We've tried to mitigate this by setting
jsc.experimental.cacheRoot
to a writable dirctory outside of the build system's control (e.g./tmp/swc
) but…Issue 2)
SWC fails intermittently when multiple processes try to write to the SWC cache at the same time.
It looks like the
wasmer
FileSystemCache
isn't safe for many processes to run concurrently. I put together a standalone repro here that runsswc
directly here: https://github.com/walkerburgin/swc-plugin-cache-reproThis fails reliably on my machine:
And this succeeds:
Trying to watch the filesystem access to the
.swc
cache directory while the failing case is running:Misc
aspect_rules_swc
: [Bug]:jsc.experimental.cacheRoot
destroys SWC performance aspect-build/rules_swc#293Input code
See: https://github.com/walkerburgin/swc-plugin-cache-repro/tree/master
Config
Playground link (or link to the minimal reproduction)
https://github.com/walkerburgin/swc-plugin-cache-repro
SWC Info output
Expected behavior
Actual behavior
Version
v1.10.18
Additional context
No response
The text was updated successfully, but these errors were encountered: