Open dovchinnikov opened 1 year ago
-javaagent is not a production-level solution for IJ
From our internal notes:
-javaagent
everywhere in each launch script is quite a lot of technical burdenBenchmarks and viability tested and logged here: https://youtrack.jetbrains.com/issue/IDEA-359879/coroutines-debugging-Investigate-split-package-problem
-javaagent
is not a production-level solution for IJ, so IJ enables coroutine debugger dynamically at very early stage of application start up:What do we have now?
kotlinx-coroutines-debug
bundles repackagedbyte-buddy
(15,3 MB out of total 20,3 MB).byte-buddy
(anywhere from 300ms to 500ms in our runs).kotlin.coroutines.jvm.internal.DebugProbesKt
which is located inkotlin-stdlib
.What should be instead?
A way to statically load the proper binary without dealing with
byte-buddy
.Why?
Possible solution
Replace stdlib's
kotlin.coroutines.jvm.internal.DebugProbesKt
with the following:This approach is already used here. JIT should not have any trouble inlining one of
== null
branches whenProbesBridge
is present or absent.ProbesBridge
should setAgentInstallationType
in its<clinit>
.ProbesBridge
should start the cleaner thread in its<clinit>
(questionable, but enables no-code setup by putting the debug jar into classpath).kotlinx-coroutines-debug-core
JAR with probes.kotlinx.coroutines.debug.internal.DebugProbesImpl
resides inkotlinx-coroutines-core-jvm
, I think that it should be a part of that JAR instead.Other solutions
kotlin-stdlib
jar statically, replacekotlin.coroutines.jvm.internal.DebugProbesKt
during build time, publish a separatekotlin-stdlib
artefact.kotlin-stdlib
jar dynamically. 2.1. Put the jar beforekotlin-stdlib
in classpath, similar to #3356. 2.2. Change IJ own class loader to loadDebugProbesKt.bin
or the proposed class whenkotlin.coroutines.jvm.internal.DebugProbesKt
is requested (somewhat equivalent to javaagent solution, also a hack).ServiceLoader
similar toDispatchers.Main
, no op implementation by default.