Increase heap size#1890
Conversation
Thevakumar-Luheerathan
requested review from
TharmiganK,
daneshk,
lnash94 and
shafreenAnfar
as code owners
📝 WalkthroughWalkthroughThe ChangesGradle Test Heap Configuration
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
There was a problem hiding this comment.
Pull request overview
This PR updates the openapi-cli module’s Gradle test configuration to allocate more heap to the TestNG test JVM, aiming to reduce intermittent failures during the full test suite run.
Changes:
- Increased the Gradle
testtask JVM heap limit foropenapi-clitests to6g. - Added inline rationale explaining why the larger heap is needed for the full TestNG suite execution.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // The full suite runs all ~890 tests in a single JVM (TestNG suite XML; forkEvery has no | ||
| // effect in suite mode). Each test does a full Ballerina compile that caches large stdlib | ||
| // modules in-JVM. The default ~4g heap is too tight, so G1 occasionally evicts the | ||
| // soft-referenced compiler cache mid-suite, intermittently breaking service type resolution | ||
| // ("Yaml was not generated"). Give it headroom. |
| dependsOn { | ||
| copyStdlibs | ||
| } | ||
| // The full suite runs all ~890 tests in a single JVM (TestNG suite XML; forkEvery has no |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
openapi-cli/build.gradle (1)
112-112: The 6g heap size is already documented with clear engineering reasoning.The code includes detailed comments explaining that the full ~890 test suite runs in a single JVM, where each test performs a full Ballerina compile that caches stdlib modules. The default ~4g heap proved insufficient because the G1 garbage collector would evict the soft-referenced compiler cache mid-suite, intermittently breaking service type resolution ("Yaml was not generated"). Increasing to 6g provides the necessary headroom to resolve this issue.
While this justification is well-documented inline, no empirical data (memory profiling or test-run results demonstrating the 4g→6g improvement) or evidence of testing intermediate values (4.5g, 5.5g) was found in the repository. If you'd like to strengthen confidence in this choice further, consider documenting the peak heap usage observed during test runs or any performance comparisons in the PR description or a README section on build configuration.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@openapi-cli/build.gradle` at line 112, The maxHeapSize setting of 6g in the build.gradle file is already well-documented with clear engineering rationale in the inline comments. To strengthen confidence in this heap size choice and provide empirical support for the decision, document in the PR description or a README section on build configuration the peak heap usage observed during test runs and include performance data or comparisons demonstrating why 4g was insufficient and why the chosen 6g value (rather than intermediate values like 4.5g or 5.5g) was the appropriate threshold.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@openapi-cli/build.gradle`:
- Line 112: The maxHeapSize setting of 6g in the build.gradle file is already
well-documented with clear engineering rationale in the inline comments. To
strengthen confidence in this heap size choice and provide empirical support for
the decision, document in the PR description or a README section on build
configuration the peak heap usage observed during test runs and include
performance data or comparisons demonstrating why 4g was insufficient and why
the chosen 6g value (rather than intermediate values like 4.5g or 5.5g) was the
appropriate threshold.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: dfc36d9a-0b07-4784-9a13-50bca95fe18a
📒 Files selected for processing (1)
openapi-cli/build.gradle
|
Closing this since the intermittent issue has been fixed via: #1892 |
Purpose
Goals
Approach
User stories
Release note
Documentation
Training
Certification
Marketing
Automation tests
Security checks
Samples
Related PRs
Migrations (if applicable)
Test environment
Learning
Summary
This pull request increases the JVM heap memory allocation for the test task in the OpenAPI CLI Gradle build configuration. The change sets the maximum heap size to 6GB to improve test suite stability and prevent intermittent build failures that occur during large-scale test execution when the default heap size is insufficient for compilation and caching operations.
Changes
testtask configuration to explicitly allocate 6GB of maximum heap sizeThis change aims to ensure more reliable test execution and prevent build failures related to memory constraints during the testing phase.