| Age | Commit message (Collapse) | Author |
|---|
|
build 84 died in bundle-web with "Gradle build daemon disappeared unexpectedly",
same as builds 76 and 77. The daemon log is what finally settled it:
Starting 8th build in daemon [uptime: 3m45s, performance: 99%, GC rate: 0.00/s,
heap usage: 0% of 2 GiB, non-heap usage: 28% of 512 MiB]
...
ValidateIrAfterLowering
Heap usage was zero. The host was 91% idle. wasm-opt was still at -Oz. None of
those were the cause: the daemon had served eight builds and by the eighth its
class metadata had filled a 512 MiB metaspace, and it died while wasm-opt's Kotlin
lowering loaded more IR classes. So this is non-heap exhaustion, and the fix is
non-heap capacity.
-XX:MaxMetaspaceSize 512m -> 1g
org.gradle.daemon=false one JVM per build, so metadata cannot pile up
Verified by reproducing the CI sequence -- clean the wasm outputs, the build
cache and the configuration cache exactly as clean-wasm-output does, then run
bundleWeb: BUILD SUCCESSFUL in 12m, no signal 9. That is the same sequence that
just failed in CI.
|
|
build 83's assemble ended with "command finished with signal 9". I had assumed
that was wasm-opt's -Oz pass list and tried to change it to -O2, which broke the
detekt gate instead (detekt parses build.gradle.kts as Kotlin source, and the
`optimizations { wasm-opt { ... } }` accessor does not resolve there -- 9
"Unresolved reference" errors). That DSL block is gone again in 4f00e13.
With the block removed, wasm-opt still runs at -Oz and both of the steps that
were dying now pass on this host:
./gradlew --max-workers=1 assemble BUILD SUCCESSFUL in 7m38s
./gradlew --max-workers=1 bundleWeb BUILD SUCCESSFUL in 3m11s
with no signal 9. So the killer was concurrency, not the optimizer level: several
JVMs (Gradle, the Kotlin daemon, wasm-opt) resident at once is what overran the
11.9 GB. The budgets are lowered to match (Gradle 3g -> 2g, Kotlin 2g -> 1.5g)
and --max-workers=1 is applied to assemble, bundles and bundle-web so only one
compile is resident at a time. The wall clock goes up, which is the trade that has
to be made for a bundle that exists.
|
|
builds 76 and 77 both died in assemble with 'Gradle build daemon disappeared
unexpectedly'. I had guessed --no-daemon would help; it did not, it just moved
the whole build into the client JVM and that died the same way. The useful
evidence was ./gradlew --status reporting every daemon as 'STOPPED (by user or
operating system)' while vmstat showed 91% of 11.9 GB idle, and the build log
complaining that 9 stopped daemons could not be reused.
What actually fixes it is the worker count. assemble with --max-workers=2
completed in 5m33s from a clean daemon registry. So:
org.gradle.parallel=false project-level parallelism off
org.gradle.jvmargs -Xmx1536m -> 3g (holds Kotlin now that it is in-process)
kotlin.daemon.jvmargs 4096m -> 2g
kotlin.compiler.execution.strategy=in-process one fewer 4 GB JVM
registry.maximum-size=1, idletimeout 2 min the pool stops accumulating
assemble step passes --max-workers=2 explicitly
bundle-web drops --no-daemon again; with the pool bounded, a normal reused daemon
is correct and faster for a ~1 min task.
|
|
Full pre-reset history preserved on branch backup/full-pre-reset (2ccab79).
|
