Vsevolod Tolstopyatov

Could you please share your microbenchmark? >Would it be possible to remove this / replace it with something cheaper? Probably yes, I'll investigate. Would be nice to know if this...

I also would like to know what the root cause of the issue is. From my experiments, `::class.java.simpleName` is roughly equivalent to the virtual method call -- so it's not...

The root cause is that Android implementation leverages the pre-Java 11 version of `getSimpleName` (https://github.com/openjdk/jdk8u-dev/blob/master/jdk/src/share/classes/java/lang/Class.java#L1305) that is not only not-cached but quite heavy as well. We might want to fix...

I'll see what can be done here; high chances are the test is [probabilistically] incorrect; there are some probabilistic tests on scheduler I wrote back in 2019 that proved themselves...

Also, it's worth adding `unwrap` function and separate stacktrace recovery check. We already bump into this in our own modules: https://github.com/Kotlin/kotlinx.coroutines/pull/2646/commits/89fd2c179efcd5a80d5dd2f12ada5a75734e9326

If we decide to follow a road with a new name, I suggest making it consistent with a potential replacement of `withContext`*. * -- it allows to break of structured...

@dkhalanskyjb while you are here, here is the rough outline of the migration plan that minimizes the impact on the codebase (e.g. we don't have to rewrite *everything* in `JobSupport`),...

@dkhalanskyjb I see, thanks for the trace. It seems like the root of the problem is that we can update the state without actually touching the tail of the list...

It is still a problem: shared mutable state for the whole app is the problem by itself; K/N GC back then was rather an obstacle than a blocker. Regarding the...

My very first proposal is to completely get rid of `setName` -- it seems to cause more harm than good. If you have any additional input about `CancellationException` stacktraces (or...