Umeshkumar9414 opened a new pull request, #8533: URL: https://github.com/apache/hbase/pull/8533
## Summary `TestMemStoreLAB#testLABChunkQueue` OOMs on machines with fast memory subsystems (e.g. Apple Silicon) even with large heap sizes (12GB+). **Root Cause:** The test spawns 10 threads allocating 256KB chunks in a tight loop for a fixed 1-second window. Once the ChunkCreator pool reaches `maxCount`, subsequent allocations use unbounded off-pool chunk creation. All chunks remain live until `mslab.close()` is called after the threads stop. On fast hardware (~5,000 iterations/thread/sec), this creates ~12.5GB in 1 second, exceeding heap. On slower x86 CI machines (~700 iter/thread/sec), only ~1.7GB is created, fitting within the default 2.2GB surefire heap. **Fix:** Add a memory guard — before each `copyCellInto`, check heap usage via `ManagementFactory.getMemoryMXBean().getHeapMemoryUsage().getUsed()` and stop allocating if used memory exceeds 80% of max heap. The 1-second time window is preserved; threads exit early only on memory-constrained JVMs. - **Before:** OOM with any heap < 13GB on Apple Silicon - **After:** Passes with 4GB heap on all hardware ## Test plan - [x] Verified `TestMemStoreLAB` (all 5 tests) passes with `-Dsurefire.Xmx=4g` on Apple Silicon - [x] Verified at heap sizes 4g, 6g, 8g, 10g, 12g — all pass after fix (all failed before) - [x] Verified chunk-recycling assertion still validates correctly (test semantics unchanged) - [x] Same vulnerable code exists in branch-2, branch-2.5, branch-2.6, and master -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
