Update to Hilt 2.48 and use the KSP version

[danysantiago]

• Moved protobuf to separate module to avoid having to wire KSP's Plugin with the Protobuf Plugin.
• @Binds function cannot be an extension function.

[tunjid]

Thanks so much @danysantiago! Why can't @Binds be an extension function?

[manuelvicnt]

@tunjid the rationale is in the release notes

[dturner]

Please fix the spotless issues by running:

./gradlew spotlessApply --init-script gradle/init.gradle.kts --no-configuration-cache

[SimonMarquis]

😢 The current version of Hilt KSP (still experimental) triggers a lot of OOMs on CI...

e: java.lang.OutOfMemoryError: Metaspace

During my tests (compilation + unit tests):

• The Kotlin compiler daemon used up to 220m of metaspace
• The Gradle daemon used up to 330m of metaspace

It seems like the current default is set by Gradle to 384m.
Should we try to increase it on CI? (we are using 1g by default on local builds)

[danysantiago]

It seems like the current default is set by Gradle to 384m. Should we try to increase it on CI? (we are using 1g by default on local builds)

Oh noes! 😢

It seems the project is already configured with 1g: https://github.com/android/nowinandroid/blob/main/gradle.properties#L11. Is this config not the same as the one in CI?

[SimonMarquis]

Oops, you're right, I was thinking of another project configuration.
We are indeed using 1g of metaspace.

The currently configured max heap space is '4 GiB' and the configured max metaspace is '1 GiB'.

kotlin.compiler.execution.strategy=in-process could be part of the issue, if both daemon adds up to this limit 🤔

[SimonMarquis]

OOF...

I confirm that ksp* tasks are responsible for these spikes in metaspace usage.
Removing kotlin.compiler.execution.strategy=in-process make these spikes less noticeable, even in the Kotlin compiler daemon which remains ~250m.

This Kotlin compiler setting was introduced in the first PR of this project #1, but I'm not sure why.

[lihenggui]

Looks like Google is aware of this issue and mentioned in the release note:

Also note that Dagger’s KSP processors are still in the alpha stage. So far we’ve focused mainly on trying to ensure correctness rather than optimize performance. Please apply due diligence when enabling ksp and report any bugs or performance issues at https://github.com/google/dagger/issues. The current list of known issues can be found here.

Shall we report an issue to them?

[manuelvicnt]

While running locally, I could see an increase in memory metadata usage but it didn't go over 1GB.

KAPT

KSP

[SimonMarquis]

@manuelvicnt did you get these results with kotlin.compiler.execution.strategy=in-process?

[manuelvicnt]

@SimonMarquis Yeah, using the current state of this PR

[danysantiago]

I've commented kotlin.compiler.execution.strategy=in-process for now to avoid the OOMs in due to increased metaspace usage. There has been reports that the spikes are due to changes in Kotlin 1.9.0 and not necessarily KSP + Hilt, the team is investigating internally but for now feel free to their hold on this PR or merge without the in-process if it works.

[JoseAlcerreca]

holding until we investigate

[jdkoren]

I'd like to look into this, what is the tool being used in this comment? #933 (comment)

[jdkoren]

@SimonMarquis which tool are you using in this comment?

[SimonMarquis]

This is VisualVM

[SimonMarquis]

FWIW:

the current implementation of the in-process strategy is suboptimal, however we have plans to improve it

https://kotlinlang.slack.com/archives/C19FD9681/p1696201557559239?thread_ts=1695989901.167479&cid=C19FD9681

[dturner]

@SimonMarquis Thanks for sharing that thread on KotlinLang. Seems like we shouldn't be using in-process anyway and it's a hangover from the original project setup.

Full context on why using in-process is suboptimal from the same thread

Currently it’s creating a new class loader for each compilation task, that may cause higher memory consumption and much slower compilation because JVM shall load classes and perform JIT compilation for the compiler classes almost from scratch. So I won’t recommend using it for the main build as I consider it consists of at least a few modules. However, it’s ok to use it for buildSrc or the single build-logic module. It shouldn’t cause any problems in this case if you’re ok with not having incremental compilation for that module.

[ffgiraldez]

I'm still having issues with hilt 1.1.0 and ksp due to OOM

[dturner]

@ffgiraldez Please could you share more details of your project and reproduction steps for the OOM by filing a new issue here: https://github.com/google/dagger/issues