Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
Thank you for the report.
When the compile time fluctuate this much, it could be caused by the JVM getting close to max memory and the GC portion of the compile time goes up.
As you have a dump, then you can easily reproduce the same build with different settings using tools/compiledump.py
. tools/compiledump.py
use the curl -O https://storage.googleapis.com/r8-releases/raw/8.3.35/r8lib.jar
(for version 8.3.35), and then add --r8-jar r8lib.jar
to the commands below. The commands all pass -da
which disables assertions. tools/compiledump.py
enabled assertions by default, but that makes compilation even slower, and AGP does not do that.
- Are you seeing the same loooooong compile time locally when running
tools/compiledump.py -da -d <dump>
? - If so you can try to pass the
-verbose:gc
to the JVM when running, should be doable like this:tools/compiledump.py -da -J=-verbose:gc -d <dump>
. Seems like the output is not streamed so you will have to wait for the command to finish. - If that shows massive GC, you can try different heap sizes, to see if changing that affects compilation time, e.g. like this:
tools/compiledump.py -da --xmx 8G -J=-verbose:gc -d <dump>
If possible you can share the dump privately with
vi...@eitv.com.br <vi...@eitv.com.br> #3
The CI calculates the values for xmx etc... depending on the current machine. The one use here should have enough resources to build the app without issues.
This is what it calculated for this particular machine, which has 32 GB of RAM (properties written inside of ~/.gradle/gradle.proprties
).
org.gradle.jvmargs = -Dfile.encoding=UTF-8 -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=1g -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -Xmx16854m -Xms16854m
kotlin.daemon.jvmargs = -Dfile.encoding=UTF-8 -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=1g -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -Xmx7223m -Xms7223m
I let gradle and kotlin use 75% of the total memory, 70% of that is for gradle, the remaining 30% for kotlin.
I once ran the build with -Dcom.android.tools.r8.printmemory
, but the CI stopped after it reached its limit of 3.5 hours. This is what I saw:
R8 is running with total memory:17683185664
R8 is running with free memory:14891000672
R8 is running with max memory:17683185664
I have multiple zips inside the directory of dumpinputtodirectory
and compiledump.py
takes roughly 10 minutes to process the largest one. Even when I pass --Xmx 8G
.
I'll try to play a bit with the memory settings and see if that's the problem, as you suspect. I could also try to run R8 in a separate process as mentioned
I'll try to can figure this out and I'll see if I can share the dump in case I can't find anything.
Thank you for the prompt response.
ti...@candyspace.com <ti...@candyspace.com> #4
I think you were right about this being a memory issue. I added the following and even after multiple tries, the minification step took 10 minutes consistently.
android {
execution {
profiles {
standard {
r8 {
jvmOptions += ["-Xms2048m", "-Xmx8192m", "-XX:+HeapDumpOnOutOfMemoryError"]
runInSeparateProcess = true
}
}
}
defaultProfile = "standard"
}
}
I don't know if something has changed, I thought 16GB were enough for gradle and R8 combined, considering that a build without R8 requires less than 8GB.
Anyway, thank you for the pointer, I think you can close this now.
aq...@google.com <aq...@google.com> #5
Thank you for the feedback, good to hear that you found a solution.
I had already written what is below, so sharing this anyway.
Each dump has the file build.properties
in the root. The one which has tool=R8
is the R8 invocation.
One other tip is to unzip the dump unzip dump.zip -d /tmp/dump
, and add --temp /tmp/dump
to running tools/compiledump.py
. Then the command printed by tools/compiledump.py
(shuld be like the one below) can be easily re-run with JVM different options without foing through the tools/compiledump.py
wrapper.
/usr/local/google/home/sgjesse/prj/r8/ws1/third_party/openjdk/jdk-11/linux/bin/javac /usr/local/google/home/sgjesse/prj/r8/ws1/src/main/java/com/android/tools/r8/utils/CompileDumpCompatR8.java /usr/local/google/home/sgjesse/prj/r8/ws1/src/main/java/com/android/tools/r8/utils/CompileDumpBase.java -d /tmp/dump -cp r8lib.jar
Running: /usr/local/google/home/sgjesse/prj/r8/ws1/third_party/openjdk/jdk-11/linux/bin/java -verbose:gc -cp /tmp/dump:r8lib.jar com.android.tools.r8.utils.CompileDumpCompatR8 --release /tmp/dump/program.jar --output /tmp/dump/out.jar --lib /tmp/dump/library.jar --classpath /tmp/dump/classpath.jar --desugared-lib /tmp/dump/desugared-library.json --desugared-lib-pg-conf-output /tmp/dump/desugared-library-keep-rules.config --pg-conf /tmp/dump/proguard.config --pg-map-output /tmp/dump/out.jar.map --min-api 23 --enable-missing-library-api-modeling
bo...@justin.tv <bo...@justin.tv> #6
In my original report, I said
ic_mr_button_disconnected_dark
andic_mr_button_disabled_dark
both havexxhdpi
,xhdpi
,hdpi
, andmdpi
versions, butic_mr_button_connected_30_dark
only hasxxhdpi
andxhdpi
versions, so maybe this is the problem?
Don't we need the same resolutions for all drawable components?
aq...@google.com <aq...@google.com> #7
Ah, apologies. I was sure we had fixed that some time ago, but the change was not merged, as far as I can tell. Thanks for pointing that out again. I'll look into this.
ap...@google.com <ap...@google.com> #8
Branch: androidx-main
commit cddba9334fdcdc5e5e7ac6df9753df7095545814
Author: Santiago Seifert <aquilescanta@google.com>
Date: Wed Nov 01 16:35:29 2023
Add missing dpi versions for ic_mr_button_connected_30_dark
Add hdpi and mdpi versions of ic_mr_button_connected_30_dark,
which are missing when compared to other drawables like
ic_mr_button_disconnected_dark and ic_mr_button_disabled_dark.
Bug: 261878418
Test: Manually using an emulator with hdpi resolution and the routing demo app.
Change-Id: I907c0581d186d5c7b58e092cda645fb1994f0757
A mediarouter/mediarouter/src/main/res/drawable-hdpi/ic_mr_button_connected_30_dark.png
A mediarouter/mediarouter/src/main/res/drawable-mdpi/ic_mr_button_connected_30_dark.png
aq...@google.com <aq...@google.com> #9
The two missing resolutions have been added in
- Let me know if I missed anything.
- Please upgrade to the next release that includes the fix.
- File a fresh bug if the issue still reproduced, but please provide more info about the patterns behind the crash, like affected API versions, affected device models and DPI.
Description
Component used: androidx.mediarouter Version used: 1.3.1 Devices/Android versions reproduced on:
When reporting bugs, please always include:
We see the following stack trace in Crashlytics, but we can't reproduce the problem locally.
mr_button_dark_static.xml
refers toic_mr_button_connected_30_dark
,ic_mr_button_disconnected_dark
, andic_mr_button_disabled_dark
.ic_mr_button_disconnected_dark
andic_mr_button_disabled_dark
both havexxhdpi
,xhdpi
,hdpi
, andmdpi
versions, butic_mr_button_connected_30_dark
only hasxxhdpi
andxhdpi
versions, so maybe this is the problem?