The following proposal is under review since July 2016, and the SIP Committee is doing a second review this month. This time, Dmitry Petrashko has updated the proposal and proposes a safer and faster scheme for the lazy val initialization, with benchmarks and a corresponding analysis. If you have a question for the author or want to propose a change, this is the best place to do it.
Regarding the issue with java.misc.unsafe for SIP-20, my understanding is that a lot of the functionality in java.misc.unsafe is being standardized (not removed) which essentially means that its being moved out of java.misc.unsafe and into some blessed package name.
I have a strong suspicion that when JDK 9 comes out, there will most likely be some shim that will allow you to use the functionality inside java.misc.unsafe in a standardised way. Also note that if java.misc.unsafe ends up being as big of an issue as is being implied if we are going to use it for this SIP, its going to be an even bigger issue in the Java ecosystem (where a huge portion of it depends either directly or indirectly on java.misc.unsafe)
I have to look at the SIP-20 proposal in more detail (and more importantly all of the recent documentation from Oracles side regarding what will and wont be in the JDK 9 version of java.misc.unsafe) but at least in my opinion completely ruling out java.misc.unsafe is too harsh at this point in time
Note also that sun.misc.unsafe is not available on Google App Engine (see e.g., https://issues.scala-lang.org/browse/SI-8362) and other restricted environments, which is the main reason we’ve removed usages from our standard library. I’d rather not add back this dependency if we can avoid it. Perhaps we can do something clever with invokedynamic to decide at linkage time which implementation to use.
It would be great to be able to use VarHandles, but requiring Java 9 for Scala 2.13 should probably be a separate SIP. (Currently, I’m personally not keen on bumping our required Java version again.)
I suppose it is possible to provide an alternative implementation of lazy vals if sun.misc.unsafe doesn’t exist. scala-offheap already does a detection to detect if its available, so if combined with invokeDynamic that can possibly work.
I think this is a better solution that var handles, at least from the POV that JDK 9 will probably take a while judging by its release history
This proposal has no owner and we’re looking for one that helps us bring it to the finish line.
If someone here wants to contribute an implementation for this, please contact me or any of the authors. To move forward on this one, the volunteer will need to discuss with the Scala team the plan on supporting JDK9 and decide which encoding to implement. I am aware that @retronym was doing some progress on this some time ago.
I think this is the right thread for an update on an old issue.
At Coursera, we had a variant of this issue, which involved only two lazy values, and the other lock being the class loader lock for a companion object.
A test case is here. (Note you have to set WORKAROUND to false to get the deadlock).
I ran some of my code (a reduced version of the race) with dotty (just installed) and the deadlock did not occur. (Not surprising). The same code reproduced the deadlock for scala 2.12