Fixed
Status Update
Comments
cc...@google.com <cc...@google.com> #2
No error occurs when compile, but when run the app, the crash will happen
cc...@google.com <cc...@google.com> #3
Project: r8
Branch: main
Author: Christoffer Adamsen <
Link:
Revert "Optimize empty Object[] -> null in reflection APIs"
Expand for full commit details
Revert "Optimize empty Object[] -> null in reflection APIs"
This reverts commit b2baa96841919a9fd14102c652f2b881fb77aa15.
Reason for revert: Causes verification errors, b/395140848
Bug: b/395140848
Change-Id: I6a3311a56443f911d0179a7a40772201fb3e687a
Files:
- D
src/main/java/com/android/tools/r8/ir/optimize/library/ClassOptimizer.java
- D
src/main/java/com/android/tools/r8/ir/optimize/library/ConstructorOptimizer.java
- D
src/main/java/com/android/tools/r8/ir/optimize/library/EmptyVarargsUtil.java
- M
src/main/java/com/android/tools/r8/ir/optimize/library/LibraryMemberOptimizer.java
- D
src/main/java/com/android/tools/r8/ir/optimize/library/MethodOptimizer.java
- M
src/test/java/com/android/tools/r8/ir/optimize/library/EmptyVarargsTest.java
Hash: 29f1b9c5d00148c170a67c8b1fa566a1a701bee6
Date: Tue Feb 11 12:02:13 2025
Description
After turning method tracing on in microbench by default in all cases, we have over time found multiple issues where runtime performance is drastically reduced after capturing a method trace, depending on OS version and ART mainline version.
We also found that it was necessary to suppress method traces on long running benchmarks to avoid ANRs, as even a single loop of a compose benchmark can take several seconds to trace. This made numbers and tracing behavior both less predictable, because duration of benchmark now defines whether it gets a method trace, since it's used to predict if simply taking a method trace on the UI thread will cause an ANR. See b/311412125
Currently, method tracing is off by default, everywhere, we want to turn it back on safely.
Tasks: