chore: size the forked test JVM heap - #391
Open
abelonogov-ld wants to merge 2 commits into
Open
Conversation
org.gradle.jvmargs sizes the Gradle daemon, not the JVM forked for tests, which Gradle leaves at its 512m default. The unit test suite runs right against that ceiling: measured over a full run of the SDK module, 1048 of 5788 GC events were full collections, against a steady live set of ~158m. At 2g the same run does 242 full collections out of 2493. Co-authored-by: Cursor <cursoragent@cursor.com>
tanderson-ld
approved these changes
Aug 18, 2026
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
3 participants
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.
Why
org.gradle.jvmargs=-Xmx4608Mingradle.propertiessizes the Gradle daemon, not the JVM Gradle forks to run tests. That one is left at Gradle's 512m default — nomaxHeapSizeis set anywhere in the build, andforkEveryis 0, so the whole module suite shares a single 512m JVM.Measured over a full run of
:launchdarkly-android-client-sdk:testReleaseUnitTestwith GC logging, the suite spends most of its collector time against that ceiling:The live set is modest, so this is headroom rather than a leak: a 512m ceiling over a ~160m working set with this much allocation churn just means constant full collections, and no margin when a test allocates a transient burst.
What this is not
This is not a fix for the intermittent
OutOfMemoryErrorinFDv2DataSourceTest. That one is a spinning loop that retains memory until it exhausts whatever heap it is given — it still OOMs at 2g — and is fixed separately in #390. Deliberately kept apart so neither change is credited with the other's effect.Test plan
./gradlew testpasses locally-Xlog:gcthat the numbers above are the before/after for the same taskNothing shipped changes, so this is
choreand should not cut a release.Note: CI on this branch may hit the
FDv2DataSourceTestflake until #390 merges, since this branch is on currentmain.Note
Overview
Build-only change: every subproject
Testtask now setsmaxHeapSize = "2g"on the forked JVM Gradle uses to run unit tests.org.gradle.jvmargsstill only sizes the Gradle daemon; without this, tests stayed on Gradle’s 512m default and the full suite spent most of its time in full GC despite a modest live set.This is aimed at faster, less GC-heavy test runs, not at fixing the intermittent
FDv2DataSourceTestOOM (that’s handled separately). Nothing in the shipped SDK changes.Reviewed by Cursor Bugbot for commit ecac6aa. Bugbot is set up for automated code reviews on this repo. Configure here.