Fixed
Status Update
Comments
to...@gmail.com <to...@gmail.com> #2
Are there any updates here?
js...@google.com <js...@google.com>
to...@gmail.com <to...@gmail.com> #4
I couldn't move the logging off thread but I was able to address an area of concern in the callstack:
com.google.protobuf.Descriptors$FileDescriptor.internalBuildGeneratedFileFrom(Descriptors.java)
com.android.build.gradle.internal.cxx.logging.CxxLogging.<clinit>(CxxLogging.java:82)
com.android.build.gradle.internal.cxx.logging.LoggingMessage.getDescriptor(LoggingMessage.java:110)
com.android.build.gradle.internal.cxx.logging.LoggingMessage.hashCode(LoggingMessage.java:489)
java.util.HashMap.hash(HashMap.java:340)
java.util.HashMap.containsKey(HashMap.java:592)
java.util.HashSet.contains(HashSet.java:204)
This logic was deduplicating messages (including chatty 'info' messages). This deduplication shouldn't be needed anymore so I removed it.
I don't know how the 80ms from comment#1 was gathered so I can't say how much it has improved logging, but it should help quite a bit. Let me know if you can still measure a performance issue. The next step would be to reduce the 'info' that's logged.
com.google.protobuf.Descriptors$FileDescriptor.internalBuildGeneratedFileFrom(Descriptors.java)
com.android.build.gradle.internal.cxx.logging.CxxLogging.<clinit>(CxxLogging.java:82)
com.android.build.gradle.internal.cxx.logging.LoggingMessage.getDescriptor(LoggingMessage.java:110)
com.android.build.gradle.internal.cxx.logging.LoggingMessage.hashCode(LoggingMessage.java:489)
java.util.HashMap.hash(HashMap.java:340)
java.util.HashMap.containsKey(HashMap.java:592)
java.util.HashSet.contains(HashSet.java:204)
This logic was deduplicating messages (including chatty 'info' messages). This deduplication shouldn't be needed anymore so I removed it.
I don't know how the 80ms from
ap...@google.com <ap...@google.com> #6
Project: r8
Branch: 2.0
commit fca7b1c8ffe433ae8f8a231301ba9a11159c5e8b
Author: Morten Krogh-Jespersen <mkroghj@google.com>
Date: Wed May 27 19:40:39 2020
Version 2.0.75
Cherry pick: Workaround for non-determinism in service loader rewriter
CL:https://r8-review.googlesource.com/51384
Cherry pick: Update synthesized $load method names
CL:https://r8-review.googlesource.com/51402
Cherry pick: Unique ServiceLoaderRewriting for each context
CL:https://r8-review.googlesource.com/51685
Bug: 157430860
Bug: 156054499
Bug: 157223339
Change-Id: Ie2b96546adfbaf9ad3717e60eb1e1eb011005f45
M src/main/java/com/android/tools/r8/Version.java
M src/main/java/com/android/tools/r8/ir/optimize/ServiceLoaderRewriter.java
A src/main/java/com/android/tools/r8/utils/IntBox.java
A src/test/java/com/android/tools/r8/rewrite/ServiceLoaderMultipleCallsTest.java
https://r8-review.googlesource.com/51721
Branch: 2.0
commit fca7b1c8ffe433ae8f8a231301ba9a11159c5e8b
Author: Morten Krogh-Jespersen <mkroghj@google.com>
Date: Wed May 27 19:40:39 2020
Version 2.0.75
Cherry pick: Workaround for non-determinism in service loader rewriter
CL:
Cherry pick: Update synthesized $load method names
CL:
Cherry pick: Unique ServiceLoaderRewriting for each context
CL:
Bug: 157430860
Bug: 156054499
Bug: 157223339
Change-Id: Ie2b96546adfbaf9ad3717e60eb1e1eb011005f45
M src/main/java/com/android/tools/r8/Version.java
M src/main/java/com/android/tools/r8/ir/optimize/ServiceLoaderRewriter.java
A src/main/java/com/android/tools/r8/utils/IntBox.java
A src/test/java/com/android/tools/r8/rewrite/ServiceLoaderMultipleCallsTest.java
mk...@google.com <mk...@google.com>
to...@gmail.com <to...@gmail.com> #7
Thanks, I see that 2.1 is now branched, does it contains this so I can play with it?
mk...@google.com <mk...@google.com> #8
The fix is a bit different but should still work the same, so yes, go right ahead.
Description
Currently doing some researches about the issue being a regression or a coroutines 1.3.7 change but R8 2.0.74 generate wrong bytecode that leads to crash
Effectively the byte code for that file contains a try to call the load2 from $$ServiceLoaderMethods:
But mapping only shows :
And bycode of ServiceLoaderMethods effectively only contains the load1 method, so load2 is missing and the crash is normal :