Hello folks, I have this build which takes a long ...
# community-supporta
Attila Pal
02/20/2024, 4:59 PMHello folks, I have this build which takes a long time and runs on low memory (15GiB does not seem enough). When I increased the memory to 20GiB or 28GiB, the total build time was not significantly different.
Could you help me improve it? This is the current configuration:
org.gradle.jvmargs=-Xmx15g XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 -XX:+UseParallelGC -XX:MaxMetaspaceSize=1gv
Vampire
02/20/2024, 5:48 PMReally hard to guess where your build spends the time and RAM from just that screenshot.
Maybe you could use the
gradle-profilera
Attila Pal
02/21/2024, 9:00 AMHere is the timeline of tasks, ordered from longest
t
Tapchicoma
02/21/2024, 2:59 PMto clarify - do you see OOM in the Gradle daemon and not in the Kotlin daemon?
a
Attila Pal
02/21/2024, 2:59 PMyes, I see it in Gradle Daemon
t
Tapchicoma
02/21/2024, 3:00 PMI highly suspect some plugin is leaking memory. I would advice you to take a heap dump of Gradle daemon heap on OOM and analyse it
a
Attila Pal
02/21/2024, 3:02 PMit is Android Gradle Plugin from Google which runs that task
t
Tapchicoma
02/21/2024, 3:04 PMwhy do you think so? AGP task may just be the last thing that caused OOM because it required some memory to run. But it may be not the actual cause of the leak
a
Attila Pal
02/21/2024, 3:04 PM Copy code
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at com.android.tools.r8.shaking.S1.a(R8_8.1.68_081071c36a35dea9a8e7845c23af618c2d62fb486760a022308124c1698d2e82:190)
at com.android.tools.r8.shaking.S1.a(R8_8.1.68_081071c36a35dea9a8e7845c23af618c2d62fb486760a022308124c1698d2e82:196)
at com.android.tools.r8.shaking.S1$$Lambda$6989/0x00007f6ca0778248.accept(Unknown Source)
at com.android.tools.r8.shaking.S1.a(R8_8.1.68_081071c36a35dea9a8e7845c23af618c2d62fb486760a022308124c1698d2e82:195)
at com.android.tools.r8.shaking.A.a(R8_8.1.68_081071c36a35dea9a8e7845c23af618c2d62fb486760a022308124c1698d2e82:68)
at com.android.tools.r8.shaking.A$$Lambda$6984/0x00007f6ca0777638.accept(Unknown Source)
at com.android.tools.r8.shaking.A.a(R8_8.1.68_081071c36a35dea9a8e7845c23af618c2d62fb486760a022308124c1698d2e82:63)
at com.android.tools.r8.shaking.a4.a(R8_8.1.68_081071c36a35dea9a8e7845c23af618c2d62fb486760a022308124c1698d2e82:88)
at com.android.tools.r8.graph.m.a(R8_8.1.68_081071c36a35dea9a8e7845c23af618c2d62fb486760a022308124c1698d2e82:259)
at com.android.tools.r8.graph.m$$Lambda$6935/0x00007f6ca0770238.a(Unknown Source)v
Vampire
02/21/2024, 3:18 PMAs @Tapchicoma said, this can just be the drop that spilled the barrel, but does not mean it is the culprit. With OOME you can practically never tell from the stacktrace where the problem is in any Java program, but always need to analyze a heap dump for example.
11 Views