You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Local bucketing leaks native memory (it's causing OOMs) #195
DevCycleLocalClient leaks native linear memory on every variableValue() call. The JVM heap stays flat while process RSS climbs ~370 bytes per evaluation, so any service doing a steady volume of evaluations eventually gets OOM-killed. We hit this regularly in production (a worker service that evaluates ~30 flags per minute).
The repro takes about 2 minutes and has some logging showing RSS space climbs while the heap stays flat.
Suspected cause
Every evaluation copies the user into the WASM bucketing module's memory to run the lookup. Normally that scratch memory should be released afterwards, but on the protobuf variable path it never is, so each call leaves a bit behind. WASM memory can only grow and never shrinks, so those leftovers pile up until the process runs out.
Looking at the decompiled LocalBucketing, getVariableForUserProtobuf allocates via newUint8ArrayParameter but never calls unpinAll() (or otherwise frees/collects), whereas other methods like generateBucketedConfig do call unpinAll(). That missing cleanup looks like the leak.
This bug was a bit more detailed, in the allocation the issue was not specifically where the AI thought it was.
The allocation was actually leaking from the config metadata path, as that was being fetched in excess beyond requirement. This data is only written once at the write time of each config, and can be cached in the Java layer instead of the WASM layer.
I've setup #201 to fix this, and once it's tested we'll get it merged in!
Massively appreciate the repro - it made things a lot quicker to debug!
Hey @robbiebowman-rf, we've released this fix as part of v2.9.6. It should be available to download/install shortly, once the Maven/Sonatype cache updates.
@robbiebowman-rf I've found the root cause of the leak, and it's actually related to a bug in the wasmtime-java library and how it's calling the invocation function with a leak.
I've gotten the leak massively minimized, but I don't know if we can get much more improvement than this:
That looks like it slows it to such a degree that our release cadence will restart pods well before they hit this OOM issue. Appreciate the diligence! I'll upgrade to 2.9.7 pronto
Activity
JamieSinn commentedon Aug 17, 2026
Hey @robbiebowman-rf - thanks for the report!
This bug was a bit more detailed, in the allocation the issue was not specifically where the AI thought it was.
The allocation was actually leaking from the config metadata path, as that was being fetched in excess beyond requirement. This data is only written once at the write time of each config, and can be cached in the Java layer instead of the WASM layer.
I've setup #201 to fix this, and once it's tested we'll get it merged in!
Massively appreciate the repro - it made things a lot quicker to debug!
Thanks!
robbiebowman-rf commentedon Aug 18, 2026
Thanks for fixing this, Jamie!
kaushalkapasi commentedon Aug 18, 2026
Hey @robbiebowman-rf, we've released this fix as part of
v2.9.6. It should be available to download/install shortly, once the Maven/Sonatype cache updates.robbiebowman-rf commentedon Aug 19, 2026
Looks like the leak is still happening, just a little slower. See new branch with updated version: https://github.com/robbiebowman-rf/devcycle-leak-mre/tree/bump-2.9.6
JamieSinn commentedon Aug 19, 2026
Can you provide a bit more info about your runtime env? I'm not able to repro with the current setup that we have. Docker or otherwise.
JamieSinn commentedon Aug 19, 2026
Here is some interesting data -
Standard test environment (M4 Mac):
JDK 25
Docker:
Looks like the reporting on the OSX side does not properly track heap/rss usage.
I've fixed this using ps and I can now see a small leak still. Interesting stackup
robbiebowman-rf commentedon Aug 19, 2026
If you checkout the branch of my reproduction repo on 2.9.6, then all you need is a DevCycle SDK key and Docker (I'm running 29.7.2, fwiw)
Then run:
robbiebowman-rf commentedon Aug 19, 2026
Yes it's definitely a slower leak than it was on 2.9.4.
JamieSinn commentedon Aug 19, 2026
@robbiebowman-rf I've found the root cause of the leak, and it's actually related to a bug in the wasmtime-java library and how it's calling the invocation function with a leak.
I've gotten the leak massively minimized, but I don't know if we can get much more improvement than this:
Unfortunately the library is 3 years out of date of WASMTime.
See #202 for the full fix details
robbiebowman-rf commentedon Aug 20, 2026
That looks like it slows it to such a degree that our release cadence will restart pods well before they hit this OOM issue. Appreciate the diligence! I'll upgrade to 2.9.7 pronto