Potential memory leak while Gradle app build benchmark

[FireHook]

Version

4.0.0

Summary

I did the migration from Apollo 2.5.12 version with such dependencies:

apollographql-apollo-api-jvm = { module = "com.apollographql.apollo:apollo-api-jvm", version.ref = "apollo" }
apollographql-apollo-coroutines-support = { module = "com.apollographql.apollo:apollo-coroutines-support", version.ref = "apollo" }
apollographql-apollo-runtime = { module = "com.apollographql.apollo:apollo-runtime", version.ref = "apollo" }
apollographql-apollo-rx3-support = { module = "com.apollographql.apollo:apollo-rx3-support", version = "2.5.14" }

To Apollo 4.0.0 with such dependencies:

apollographql-apollo-runtime = { module = "com.apollographql.apollo:apollo-runtime", version.ref = "apollo" }
apollographql-apollo-normalized-cache = { module = "com.apollographql.apollo:apollo-normalized-cache", version.ref = "apollo" }

I have noticed that Gradle Profiler throws java.lang.RuntimeException: Multiple Gradle daemons were used. exception during Gradle app build benchmarking using gradle-profiler --gradle-user-home ../benchmark --benchmark --measure-config-time --profile buildscan --scenario-file scripts/buildprofiler/clean_build_scenario --output-dir apk_debug_build, where clean_build_scenario is five times iteration of :app:assembleDebug with --no-build-cache and --no-configuration-cache arguments.

Further investigation shown that Memory leaks might be occurred.

Gradle Profiler Meatspace memory usage while app benchmarking with Apollo 2.5.12

Gradle Profiler Meatspace memory usage while app benchmarking with Apollo 4.0.0

As you can see from screenshots while Apollo 4.0.0 were used, the Meatspace memory used by Gradle increases within each iteration, so it looks like these are memory leaks.

I have tried updating Apollo to newer 4.1.0 version but the problem does not eliminate.

Could you, please, take a look what can cause the issue?

Steps to reproduce the behavior

No response

Logs

(Your logs here)

[martinbonnin]

Thanks for opening this. 4.0.0 uses a separate classloader for running codegen in order to support compiler plugins. That sounds like a potential culprit. I'll dig into this.

[martinbonnin]

@FireHook I could reproduce. There is a Gradle issue about this: gradle/gradle#18313

As a workaround, #6267 introduces Service.useProcessIsolation to run the required Apollo tasks in a separate process and therefore reclaim the memory and the end of the task when the process terminates.

It's a tradeoff though as the task may take a bit more time to start (forking, etc...).

In the future, I'm planning to migrate the Gradle plugin to Gratatouille. This will give us more control over the classloader. We'll need to remove Service.packageNameGenerator and Service.operationOutputGenerator first though.

In the meantime, if the leak is too annoying for you, set useProcessIsolation to true:

Edit: no need for useProcessIsolation see comment below
Edit: also linking a similar KGP issue: https://youtrack.jetbrains.com/issue/KT-68136

[martinbonnin]

Update: we investigated this with @scana and ended with a more universal solution. Latest SNAPSHOTs do not need useProcessIsolation.set(true) anymore. That will be available in 4.1.1

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Kotlin usage and allow us to serve you better.