Noticeable upfront cost of Dispatchers.Default

[semoro]

Describe the problem

Creation of the CoroutineScheduler requires initialization of kotlin.random.Random, which, in the case of kotlin-stdlib-jdk8 is used, requires dynamic class-loading of android.os.BUNDLE (see: https://youtrack.jetbrains.com/issue/KT-44089)

However, Dispatchers.Default is often used early in the application runtime when startup logic uses coroutines, and additional class-loading delays are unfortunate.
See github: "main" /Dispatchers.Default/ for examples.

Profiler result

Provide a Reproducer

// FILE: main.kt
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.delay
import kotlinx.coroutines.runBlocking


fun main() {
    val dispatcher = Dispatchers.Default
    runBlocking {
        delay(1000)
    }

    subCall(dispatcher)
}

suspend fun mainImpl() {
    println("done")
}

// FILE: other.kt
import kotlinx.coroutines.CoroutineDispatcher
import kotlinx.coroutines.runBlocking

fun subCall(dispatcher: CoroutineDispatcher) {
    // This runBlocking is causing a long kotlin.Random.<clinit>
    runBlocking(dispatcher) {
        mainImpl()
    }
}

build.gradle.kts

// FILE: build.gradle.kts

plugins {
  kotlin("jvm") version "1.9.21"
}

group = "org.example"
version = "1.0-SNAPSHOT"

repositories {
  mavenCentral()
}

dependencies {
  implementation(kotlin("stdlib-jdk8"))
  testImplementation("org.jetbrains.kotlin:kotlin-test")

  // dependency on Kotlinx-coroutines
  implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0")
}
kotlin {
  jvmToolchain(21)
}

[qwwdfsad]

Worth noting that this code path is noticeable during our IDE startup, when Dispatchers.Default is initialized

Additional validation:

1. Running the trivial runBlocking + launch(Dispatchers.Default) with async-profiler start-n-profile.
   Note that it requires really high sampling interval

Flamegraph

Can be run as java -agentpath:/Users/qwwdfsad/workspace/async-profiler-3.0-macos/lib/libasyncProfiler.dylib=start,event=cpu,interval=100000,file=profile.html -jar main.jar.
In short, ~10% of the main code spent in the initialization of the first worker, ~70% of that time is spent in Random initialization

2. Startup is a subtle matter, so it's worth double-checking with something more deterministic.
   I've used -XX:+TraceBytecodes (note: you'll need fastdebug JDK for that).

The resulting flamegraph:

Flamegraph


The same results w.r.t. relative cost