This is a condensed description of the issue Space is suffering, so some details (e.g. the actual CPU impact, CPU snapshots, etc.) are omitted.

For coroutines, in order to keep track of ThreadContextElement, each undispatched (the one that doesn't change current coroutine dispatcher) withContext, a special thread-local variable is spawned in order to preserve and restore execution context in the corresponding thread.

It leads to multiple problems:

• If the coroutine does not use thread-local elements, the corresponding system ThreadLocal is instantiated and queried, while being later reset to null
• If system-wide ThreadContextElement is used in the application, then application spawns as much thread locals as there are calls to `withContext.

The rest is ThreadLocal implementation peculiarities:

• ThreadLocal is actually stored in Thread's local map with open addressing by weak reference
• ThreadLocal map entry is allocated on the first access (e.g. get()) even if it's null or wasn't set and has no initializer
• If ThreadLocal is unreachable, it's collected, but its weak-reference slot is not
• When thread-local map has reached its fill factor or encountered "stale" (GC-collected) entry, it attempts to clean it up with potential rehash
• If coroutine lives long enough, it is promoted to old generation along with its ThreadLocal object
  • Because of that, entry can only be collected after an old generation GC which is rare enough event
  • Until then, any thread-local op that encounters rehash/stale entry will burn quite a lot of CPU processing 4k+ open-addressing hashmap