Status Update
Comments
cc...@google.com <cc...@google.com> #2
Process: work, PID: 7773
java.util.ConcurrentModificationException
at
androidx.compose.runtime.snapshots.StateListIterator.validateModification(SnapshotStateList.kt:297)
at androidx.compose.runtime.snapshots.StateListIterator.next(SnapshotStateList.kt:276)
at
.DashboardViewModel$getCarousalListApi$1$1$1.invokeSuspend(DashboardViewModel.kt:751)
at
.DashboardViewModel$getCarousalListApi$1$1$1.invoke(Unknown
Source:8)
at
.DashboardViewModel$getCarousalListApi$1$1$1.invoke(Unknown
Source:2)
at
.config.common.ExtensionsKt$launchOnIOWithCompletion$1.invokeSuspend(Extensions.kt:28)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@5443283, Dispatchers.IO]
cc...@google.com <cc...@google.com> #3
reverse()
constructs two iterators (if the list is > 18 in size), one forward walking and one backwards walking and will modify the array using both iterators. This is currently treated as a concurrent modification as the array was modified after the iterator was created. This is too strict for the Java algorithms. They expect a concurrent modification exception to only be thrown if a structural chagne to the list is made, e.g. an insert or delete, not a value change.
First, mutableStateListOf()
lists will be changed to not interpret setting the value of the slot of an element as a concurrent. Second, they will be changed to support RandomAccess
which avoids the algorithms using the iterators for operations that would be faster if they used get
and set
directly.
ra...@google.com <ra...@google.com>
ra...@google.com <ra...@google.com> #4
Branch: androidx-main
commit 75f720e1695c3574930d0385211341fac876a834
Author: Chuck Jazdzewski <chuckj@google.com>
Date: Thu Sep 14 15:22:33 2023
Relax concurrent modification exception for snapshot state list
The snapshot state list iterator considered any change made outside the
iterator as a concurrent change. This change relaxes the checking to
only consider structural changes (adding and removing) to be treated as
a concurrent change. This allows SnapshotStateList to be used with
`reverse()` which assumes that setting the value of an element is not a
concurrent change.
Adds RandomeAccess interface to MutableStateList to signal collection
extensions functions they can use direct indexing versions of their
algorithm.
Corrects the set() after a call previous() to update the correct
element.
Fixes: 219554654
Test: ./gradlew :compose:r:r:tDUT
Relnote: """SnapshotStateList is not marked as RandomAccess to enable
the direct indexing version of list helpers to be used"
Change-Id: I5210ca5c0f490619381ecf93ac0b1ccb03071e36
M compose/runtime/runtime/api/current.txt
M compose/runtime/runtime/api/restricted_current.txt
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/snapshots/SnapshotStateList.kt
M compose/runtime/runtime/src/nonEmulatorCommonTest/kotlin/androidx/compose/runtime/snapshots/SnapshotStateListTests.kt
cc...@google.com <cc...@google.com>
cc...@google.com <cc...@google.com> #5
ap...@google.com <ap...@google.com> #6
Branch: androidx-main
commit d5fb7b68ab904d904c21cbb8ce0bf497979ff6a1
Author: Chris Craik <ccraik@google.com>
Date: Tue Oct 18 14:16:36 2022
Add summing mode to TraceSectionMetric
Test: TraceSectionMetricTest
Relnote: """
Added TraceSectionMode("label", Mode.Sum), allowing measurement of
total time spent on multiple trace sections with the same label. For
instance, TraceSectionMetric("inflate", Mode.Sum) will report a metric
`inflateMs` for the total time in a trace spent on inflation.
Also removed API requirement, as TraceSectionMetric works together
with androidx.tracing.Trace back to lower API levels, with the use of
[forceEnableAppTracing](
"""
Additionally adds tracing of cache_miss and cache_hit for observing
cost of shader compilation for
Change-Id: Id7b68e23f5ded4d20ab21771dbf9eb96d9dcfdb7
M benchmark/benchmark-macro/api/public_plus_experimental_current.txt
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/TraceSectionMetricTest.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/Metric.kt
M compose/integration-tests/macrobenchmark/src/androidTest/java/androidx/compose/integration/macrobenchmark/SmallListStartupBenchmark.kt
M testutils/testutils-macrobenchmark/src/main/java/androidx/testutils/MacrobenchUtils.kt
ap...@google.com <ap...@google.com> #7
Branch: androidx-main
commit 0ba5c3dad9652a85319894f9aa7ad52664be72d2
Author: Chris Craik <ccraik@google.com>
Date: Tue Oct 18 20:56:23 2022
Fix deleteShaderCache by using Profileinstaller or fallback correctly with root
Test: SmallListStartupBenchmark
Test: MacrobenchmarkScopeTest
Fixes: 231455742
Relnote: """
BENCHMARK RELEASE NOTES
Fixed MacrobenchmarkScope.dropShaderCache(). This removes roughly 20ms
of noise from StartupMode.COLD benchmarks, as shaders are now
consistently cleared each iteration. Previously, `Partial` compilation
using warmup iterations would report incorrectly fast numbers, as
shader caching was more likely to happen during warmup. This fix
requires either a rooted device, or using
`profileinstaller:1.3.0-alpha02` in the target app.
PROFILEINSTALLER RELEASE NOTES
Added a hook for benchmarks to drop the shader cache, to ensure
consistent performance for cold startups, especially when compiling
with profiles from warmup iterations. This update is required to
measure cold startups using `benchmark-macro-junit4:1.2.0-alpha05` or
later.
"""
Change-Id: Ia5171b0f40dd8ce6f64f5ccf0a33281a4d8b121e
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/MacrobenchmarkScopeTest.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/Macrobenchmark.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/MacrobenchmarkScope.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/ProfileInstallBroadcast.kt
M profileinstaller/profileinstaller/api/current.txt
M profileinstaller/profileinstaller/api/public_plus_experimental_current.txt
M profileinstaller/profileinstaller/api/restricted_current.txt
A profileinstaller/profileinstaller/src/main/java/androidx/profileinstaller/BenchmarkOperation.java
M profileinstaller/profileinstaller/src/main/java/androidx/profileinstaller/ProfileInstallReceiver.java
M profileinstaller/profileinstaller/src/main/java/androidx/profileinstaller/ProfileInstaller.java
na...@google.com <na...@google.com> #8
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.benchmark:benchmark-macro:1.2.0-alpha07
androidx.profileinstaller:profileinstaller:1.3.0-alpha02
Description
Alert on dashboard:https://androidx-perf.skia.org/t/?begin=1651608277&end=1651608278&subset=all
CLs in build:https://android-build.googleplex.com/builds/jump-to-build/8534762
Caused byhttps://android-review.googlesource.com/c/platform/frameworks/support/+/2086023/ - Improve macrobench iter speed by optimizing shell commands
Regression only affects baseline profile and full compilation variants of cold startup benchmarks.
Need to see if this makes the numbers more or less correct, and why. Triaging to 1.1 for this reason.