[SPARK-57952][CORE][TESTS] Retry retryOnOOM a few times to reduce SorterSuite flaky OOM#57029
Closed
HyukjinKwon wants to merge 1 commit into
Closed
[SPARK-57952][CORE][TESTS] Retry retryOnOOM a few times to reduce SorterSuite flaky OOM#57029HyukjinKwon wants to merge 1 commit into
HyukjinKwon wants to merge 1 commit into
Conversation
…te flaky OOM SorterSuite's 'SPARK-11072 ...' test allocates a single ~1GB byte array and wraps it in retryOnOOM (SPARK-57037), which does one GC + one retry. In memory-constrained Maven CI this still OOMs intermittently (~1 in 5 core-module runs): a single System.gc() after the first failure does not always reclaim the prior test's large array in time, so the lone retry allocates against a still-pressured heap and fails. Retry a few times (default 3), running a full runGC() (which waits for a weak reference to clear) between attempts, to give the JVM more chances to reclaim memory. This is a flakiness reduction, not a correctness change: an unbounded/too-large allocation still fails once attempts are exhausted, so genuine OOMs are not masked. Co-authored-by: Isaac
dongjoon-hyun
approved these changes
Jul 6, 2026
HyukjinKwon
added a commit
that referenced
this pull request
Jul 6, 2026
…erSuite flaky OOM ### What changes were proposed in this pull request? Make the test helper `retryOnOOM` (in `SparkFunSuite`) retry a few times (default 3) with a full `runGC()` between attempts, instead of running GC and retrying only once. The sole caller (`SorterSuite`) is updated to the new `retryOnOOM()(body)` form. ### Why are the changes needed? The `core` module test job intermittently aborts with an OOM (observed ~1 in 5 runs, e.g. in the branch-4.x Maven build): ``` *** RUN ABORTED *** An exception or error caused a run to abort: Java heap space java.lang.OutOfMemoryError: Java heap space at org.apache.spark.util.collection.SorterSuite.$anonfun$new$12(SorterSuite.scala:145) at org.apache.spark.SparkFunSuite.retryOnOOM(SparkFunSuite.scala:122) ``` `SorterSuite` allocates a single ~1 GB `byte[]` (heap is `-Xmx4g`). SPARK-57037 already wrapped that allocation in `retryOnOOM`, which does one `System.gc()` + one retry. But a single GC after the first failure does not always reclaim the previous test's large array in time, so the lone retry allocates against a still-pressured heap and OOMs again. Because the failure is intermittent (the job passes ~4 of 5 runs), 4 GB is not fundamentally too small — this is transient heap pressure, exactly the case where additional GC+retry attempts help. Retrying up to 3 times (with `runGC()`, which waits for a weak reference to clear, between attempts) gives the JVM more chances to reclaim memory. This is a test flakiness reduction, not a correctness change: a genuinely too-large or leaked allocation still fails once the attempts are exhausted, so real OOMs are not masked. ### Does this PR introduce _any_ user-facing change? No. Test-only change. ### How was this patch tested? `SorterSuite` (which exercises `retryOnOOM`) on a fork via GitHub Actions; confirmed the signature change compiles and the suite passes. **CI evidence** - Failing run (apache/spark, branch-4.x `build_maven`, `core` module — SorterSuite OOM): https://github.com/apache/spark/actions/runs/28747189185 - Passing validation (fork, compiles `core` + runs `SorterSuite`): https://github.com/HyukjinKwon/spark-agent6/actions/runs/28766544512 Note: the underlying OOM is intermittent (~1/5), so this reduces the flake probability; it is not claimed to statistically eliminate it. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.8) Closes #57029 from HyukjinKwon/ci-fix/agent6-oom-pr. Authored-by: Hyukjin Kwon <gurwls223@apache.org> Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com> (cherry picked from commit 5ae5aa5) Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com>
HyukjinKwon
added a commit
that referenced
this pull request
Jul 6, 2026
…erSuite flaky OOM ### What changes were proposed in this pull request? Make the test helper `retryOnOOM` (in `SparkFunSuite`) retry a few times (default 3) with a full `runGC()` between attempts, instead of running GC and retrying only once. The sole caller (`SorterSuite`) is updated to the new `retryOnOOM()(body)` form. ### Why are the changes needed? The `core` module test job intermittently aborts with an OOM (observed ~1 in 5 runs, e.g. in the branch-4.x Maven build): ``` *** RUN ABORTED *** An exception or error caused a run to abort: Java heap space java.lang.OutOfMemoryError: Java heap space at org.apache.spark.util.collection.SorterSuite.$anonfun$new$12(SorterSuite.scala:145) at org.apache.spark.SparkFunSuite.retryOnOOM(SparkFunSuite.scala:122) ``` `SorterSuite` allocates a single ~1 GB `byte[]` (heap is `-Xmx4g`). SPARK-57037 already wrapped that allocation in `retryOnOOM`, which does one `System.gc()` + one retry. But a single GC after the first failure does not always reclaim the previous test's large array in time, so the lone retry allocates against a still-pressured heap and OOMs again. Because the failure is intermittent (the job passes ~4 of 5 runs), 4 GB is not fundamentally too small — this is transient heap pressure, exactly the case where additional GC+retry attempts help. Retrying up to 3 times (with `runGC()`, which waits for a weak reference to clear, between attempts) gives the JVM more chances to reclaim memory. This is a test flakiness reduction, not a correctness change: a genuinely too-large or leaked allocation still fails once the attempts are exhausted, so real OOMs are not masked. ### Does this PR introduce _any_ user-facing change? No. Test-only change. ### How was this patch tested? `SorterSuite` (which exercises `retryOnOOM`) on a fork via GitHub Actions; confirmed the signature change compiles and the suite passes. **CI evidence** - Failing run (apache/spark, branch-4.x `build_maven`, `core` module — SorterSuite OOM): https://github.com/apache/spark/actions/runs/28747189185 - Passing validation (fork, compiles `core` + runs `SorterSuite`): https://github.com/HyukjinKwon/spark-agent6/actions/runs/28766544512 Note: the underlying OOM is intermittent (~1/5), so this reduces the flake probability; it is not claimed to statistically eliminate it. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.8) Closes #57029 from HyukjinKwon/ci-fix/agent6-oom-pr. Authored-by: Hyukjin Kwon <gurwls223@apache.org> Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com> (cherry picked from commit 5ae5aa5) Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com>
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
Make the test helper
retryOnOOM(inSparkFunSuite) retry a few times (default 3) witha full
runGC()between attempts, instead of running GC and retrying only once. The solecaller (
SorterSuite) is updated to the newretryOnOOM()(body)form.Why are the changes needed?
The
coremodule test job intermittently aborts with an OOM (observed ~1 in 5 runs, e.g.in the branch-4.x Maven build):
SorterSuiteallocates a single ~1 GBbyte[](heap is-Xmx4g). SPARK-57037 alreadywrapped that allocation in
retryOnOOM, which does oneSystem.gc()+ one retry. But asingle GC after the first failure does not always reclaim the previous test's large array
in time, so the lone retry allocates against a still-pressured heap and OOMs again.
Because the failure is intermittent (the job passes ~4 of 5 runs), 4 GB is not fundamentally
too small — this is transient heap pressure, exactly the case where additional GC+retry
attempts help. Retrying up to 3 times (with
runGC(), which waits for a weak reference toclear, between attempts) gives the JVM more chances to reclaim memory.
This is a test flakiness reduction, not a correctness change: a genuinely too-large or
leaked allocation still fails once the attempts are exhausted, so real OOMs are not masked.
Does this PR introduce any user-facing change?
No. Test-only change.
How was this patch tested?
SorterSuite(which exercisesretryOnOOM) on a fork via GitHub Actions; confirmed thesignature change compiles and the suite passes.
CI evidence
build_maven,coremodule — SorterSuite OOM):https://github.com/apache/spark/actions/runs/28747189185
core+ runsSorterSuite):https://github.com/HyukjinKwon/spark-agent6/actions/runs/28766544512
Note: the underlying OOM is intermittent (~1/5), so this reduces the flake probability;
it is not claimed to statistically eliminate it.
Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.8)