Fix race condition in new LazyVals

[szymon-rd]

Resolve #16806

In the repro, Evaluating was generated as a subtype of Serializable, and the type of lazy value was erased to Serializable - these together broke the optimized condition checking if the value is initialized. For lazy val of type A we were checking if LazyValControlState <: A, and if that was not the case, we assumed it would be safe to just generate the condition _value.isInstanceOf[A]. If that condition was true in runtime, we assumed that the value was already calculated and returned it. If it was Evaluating and A =:= Serializable, then we assumed so falsely. The easiest fix is to just make the LazyValControlState <: Serializable, I will check if it doesn't affect performance.

[szymon-rd]

I see the problem, I can't use java.io.Serializable. Actually I can, it's present in scala.js and native.

[sjrd]

That was quite subtle!

Perhaps add a comment above LazyValControlState explaining why it extends Serializable?

[smarter]

FWIW, Scala 2 uses jcstress to stress-test concurrency tests: scala/scala@3783fe8, it would be good if we could stress-test lazy vals that way too.

[szymon-rd]

@sjrd How can I test this with scalajs? There is some linking error.

[sjrd]

You cannot do it with something based on Semaphore or any other blocking stuff.

But anyway it does not matter on Scala.js, since Scala.js only uses a single thread and therefore always uses the non-thread-safe lazy val implementation. So you can skip it on Scala.js with

// scalajs: --skip