On JVM worker threads retain context class loader

[dovchinnikov]

Describe the bug

If a thread happens to start from a thread with different context class loader, then the class loader is retained for an unforeseeable time (at least for IDLE_WORKER_KEEP_ALIVE_NS, may be longer under load). In multi-loader environment this causes a leak.

Provide a Reproducer

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking

class MyClassLoader : ClassLoader()

fun main() {
  val custom = MyClassLoader()
  runBlocking {
    val current = Thread.currentThread().contextClassLoader
    try {
      Thread.currentThread().contextClassLoader = custom
      launch(Dispatchers.Default) {} // spawn new thread
    }
    finally {
      Thread.currentThread().contextClassLoader = current
    }
  }
  println("A place for breakpoint")
}

[dovchinnikov]

Similar leak in IJ thread pools: https://youtrack.jetbrains.com/issue/IDEA-239033, I think coroutine scheduler pool is also prone to that, although I cannot provide reliable repro.

Edit: IJ platform fix of this problem JetBrains/intellij-community@20931fc

[qwwdfsad]

The behaviour of Dispatchers.Default mimics any other executor on the JVM -- the threads are created in the current thread context classloader. Typically, it's possible to work around it by supplying your own ThreadFactory, but not for the "global" dispatcher that relies on a specific thread subclass.

It seems like it makes sense to set the thread's context to the same context classloader as the Dispatchers.Default itself, but I would like you to confirm it fixes the issue for you