Theme toggling causes significant memory usage increase

[janbarari]

🐛 Describe the bug

I was building my app with Nucleus and Jewel UI when I noticed that toggling the theme causes memory usage to increase significantly. I then opened the Nucleus demo app and tried the same thing, and the issue occurs there as well. Since the Nucleus demo app doesn’t use Jewel UI, I don’t think it’s related to Jewel.

Screen.Recording.2026-08-20.at.1.34.14.PM_compressed.mp4

📱 Tech info

• Device: iMac 2017
• OS: 13.7.8
• Library/App version: Nucleus Demo 2.4.7

[janbarari]

Maybe relevant with #541

[kdroidFilter]

First, we need to check if vanilla compose also has this bug.

[kdroidFilter]

I reproduced this e2e on macOS 26 / M4, both with the demo itself (200 theme toggles, maximized window) and with two twin packaged apps — vanilla Compose Window vs Nucleus Tao, identical content, same window — measuring the process footprint (= Activity Monitor Memory) from outside, not the Java heap.

Nucleus Tao: 286 MB → 343 MB peak → 301 MB after 30 s idle; vanilla Compose: flat 420–436 MB, peak 496 MB. All the movement is Skia's Metal cache (Owned physical footprint (unmapped) (graphics): 50 → 84 → back to 50 MB) while the Java heap, its committed size and IOSurface stay flat — a bounded GPU cache, not a leak, and Tao's peak stays below vanilla's floor (vanilla just pre-allocates 168 MB of IOSurface up front and never gives it back, so it never appears to "grow").

So I can't reproduce a leak here, and I don't have an Intel Mac on macOS 13 to test yours: does the number come back down ~30 s after you stop clicking, and does it keep climbing past a plateau if you keep toggling (and at what window size)? That distinguishes normal GPU-cache fill from a real leak on Intel.

[sonic-onkaringale]

@janbarari It is a real issue, It happens on Vanilla Compose too.
I face this on my Mac too, and mine is Apple Silicon.
Can you share like which JDK you are using, because at this point we just have to find common ground.
I will be testing more coming this weekend.

[kdroidFilter]

Nucleus recommends using OpenJDK temurin for Mac and Linux, and the Microsoft fork for Windows. For development, I use JBR for Compose Hot Reload.

[kdroidFilter]

Could you try calling system.gc every time you change the theme? I imagine that could be a workaround

[kdroidFilter]

It would also be interesting to try it with/without Proguard

[janbarari]

I’m using JBR 25. It happens on Windows as well.

[janbarari]

The results are interesting:

• With or without ProGuard: No noticeable difference.

• With System.gc(): It works as expected, keeping memory usage close to its level before the animation or theme toggling.

• Without System.gc(): After 10–20 toggles, memory usage increased to approximately 580 MB.

• Current behavior: My app memory usage remains around 240 MB ish, regardless of whether the theme is toggled.

[janbarari]

Also, calling System.gc() did not affect the app’s normal behavior - there was no animation jitter or lag.

[janbarari]

Thanks for the suggestion, @kdroidFilter . I guess I’ll have to use System.gc() in similar parts of my app to help control memory usage.