Hi! Is anyone experiencing OOM issues on building ...

# multiplatform

[Stan]

Hi! Is anyone experiencing OOM issues on building XCFramework?
We regularly get OOM or GC overhead limit errors when building release XCFramework.
Our props are:

org.gradle.jvmargs=-Xmx16g -Xms6g -XX:+UseParallelGC -XX:+UseGCOverheadLimit -XX:GCTimeLimit=10 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseStringDeduplication -Dfile.encoding=UTF-8 -Dkotlin.daemon.jvm.options=-Xmx16g

Machine is mac with 32 gb RAM
Kotlin 2.1.10
Compose 1.7.1

During debug we can see that the issue is happening on devirtualization phase. Seems like it loading tons of compose related classes, but almost not unloading anything.

[tapchicoma]

try to increase heap size via kotlin.native.jvmArgs - by default it uses 3g

[Stan]

@tapchicoma yes we tried also on 128g macs with this setup

org.gradle.jvmargs=-Xmx22g -Xms6g -XX:+UseParallelGC -XX:+UseGCOverheadLimit -XX:GCTimeLimit=10 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseStringDeduplication -Dfile.encoding=UTF-8 -Dkotlin.daemon.jvm.options=-Xmx22g -Dkotlin.native.jvm.options=-Xmx22g

and also separate line as you suggested
it just randomly fails in most of attempts

[tapchicoma]

Then could you take a heap dump and upload it to https://uploads.jetbrains.com/?

[tapchicoma]

I suppose heap dump not from the Gradle daemon process, but from the process running Kotlin/Native linking phase

[Stan]

yes, sure. btw when it succeeds the build time is very different

[Stan]

Upload id: 2025_03_12_zpywhEBurZaoL3yrgVTncE (file: java_pid1722.hprof)

[tapchicoma]

@sergey.bogolepov could you check it? 👏

[Stan]

appreciate your help with this, currently 90% of our release are failing. We are building in parallel 2 targets arm64 and simulator and one of the builds is consistently failing with OOM or GC overhead limit (even with disabled limit).

[Stan]

is it possible to disable devirtualization phase?

[Stan]

also created this issue to track
https://youtrack.jetbrains.com/issue/CMP-7763/OOM-errors-when-building-release-XCFramework-on-devirtualization-phase

[Stan]

Hi @sergey.bogolepov let me know if you need more info

[sergey.bogolepov]

You can try passing -Xdisable-phases=Devirtualization with something like

kotlin.targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
  binaries.all {
    freeCompilerArgs += "-Xdisable-phases=Devirtualization"
  }
}

Note that it affects all other release optimizations, thus runtime performance.
What if you run builds sequentially instead of parallel?

[sergey.bogolepov]

Almost forgot: thanks for the report! :)
We will take a closer look at the ticket. Devirtualization is known to be memory-hungry, and there might be a few things that could go wrong.

[Stan]

ok thank you, we will try to disable just as experiment, but sure it's not a solution to go in prod

[Stan]

we run builds in parallel on different machines, so no difference

[Stan]

checked with disabled devirtualization, still got OOM

[Brill]

I get them when i try to do a Build -> Clean and assemble (I'm in canary 8 ), but its find if i build to device or compile with xcode.

[Stan]

hi @sergey.bogolepov do you have any findings?

[sergey.bogolepov]

Sorry, I haven't had much time lately. Could you please check your project with 2.1.20?

[Stan]

we checked it, with upgrade and downgrade kotlin version, no change