Fix CallbackStack leak on JS

[armanbilge]

Fixes the JS version of #3359, since CallbackStack is specialized on JS.

clearCurrent() is now implemented by invoking the JS delete operator on that array index. This transforms the js.Array into a sparse (aka "holey") array. This does de-optimize the data structure compared to a packed array, but hopefully this is good enough for our purposes (and better than a userland data structure).

For real-world coding patterns, the performance difference between accessing holey or packed arrays is usually too small to matter or even be measurable.

https://v8.dev/blog/elements-kinds#avoid-creating-holes

[djspiewak]

This definitely staunches the bleeding, but I'd also be curious as to how this compares to the old LongMap approach, since that's effectively what a sparse array is.

[armanbilge]

but I'd also be curious as to how this compares to the old LongMap approach, since that's effectively what a sparse array is.

You mean this LongMap?

cats-effect/kernel/shared/src/main/scala/cats/effect/kernel/Deferred.scala

Lines 92 to 94 in 130fdcc

	private[this] val ref = new AtomicReference[State[A]](
	State.Unset(LongMap.empty, State.initialId)
	)

That's all immutable state there, which means allocations, which means this will blast it out of the water 😛

Edit: also note that JS doesn't natively support 64 bit ints, so anything with Long has lots of overhead.

[armanbilge]

This transforms the js.Array into a sparse (aka "holey") array. This does de-optimize the data structure compared to a packed array, but hopefully this is good enough for our purposes

Tangential, but while investigating this I discovered that Scala.js is (unintentionally) de-optimizing all uses of js.Array in its stdlib/javalib, so performance can't be that bad.