across two different gradle-profiler scenario runs...

# k2-adopters

[Zac Sweers]

across two different gradle-profiler scenario runs of github.com/zacsweers/catchup, I see strange behavior where the K2 compiler becomes significantly slower after a few runs. The scenario run is available in the repo on the z/k2 branch

[Zac Sweers]

and again on a third run. Seems to consistently happen on the 7th iteration (after 5 warmup iterations)

[Zac Sweers]

my theory is that the gradle daemon is being killed due to memory pressure. Not sure what to do about it though, and gradle-profiler hides this event from its output

[Zac Sweers]

pretty sure it’s gradle killing its own daemons despite running under a benchmark, and I’ve got no idea what to do about this to get it to stop doing this

[juliocbcotta]

Attach a profiler ( I like VisualVM) to the gradle daemon running the gradle-profiler process and check the memory usage and GC

[Zac Sweers]

I was able to get this working by bumping up the max memory. Looks like KSP2 uses quite a lot of memory

[juliocbcotta]

What if you double the number of build executions? Does the benchmark still run fully? It may be the case of a memory leak in some gradle plugin, if you execute the benchmark and let a process profiler running, you should see the memory usage flatten out after a few builds otherwise a memory leak may be happening...

[Zac Sweers]

I think there may be one, it climbs slightly throughout. I never know how to read gradle daemon heap dumps though

[juliocbcotta]

It is hard indeed, when I found a memory leak, I had to create a sample project and run benchmarks applying all plugins to reproduce the issue, and then removing one plugin each time to check what was going on... In the end it was a class loader in room ksp plugin being loaded multiple times, very far from my capabilities of debugging