Please sign in to comment.
initializes lazy vals and inner objects in advance
As discussed at http://groups.google.com/group/scala-internals/browse_thread/thread/97840ba4fd37b52e, `synchronized(this)` employed by lazy val and inner object initialization is an excellent way to deadlock yourself in the foot. Imagine a thread, which grabs a reflection GIL and then calls one of those lazy vals / objects that reflection exposes (e.g. a companion module of an innocently looking SingleType case class). Then imagine another thread, which calls something else in SymbolTable, grabbing symbol table's monitor, and then tries to get a reflection GIL to do something non-trivial. Hello, we've just arrived at a deadlock. Since, as discussed in the aforementioned thread, there's no easy way to change lazy vals / inner objects in reflection to use GIL instead of synchronizing on this, I bit the bullet and manually initialized all things with deferred initialization defined in reflect.runtime.SymbolTable. The list of all things `$lzycompute` has been mined by a simple Python script, then I copy/pasted that list into `JavaUniverse.scala` and went ahead forcing objects and lazy vals mentioned there. Notably, I've been able to force all lazy vals in Definitions.scala. There are some todos left, but I suggest we move forward without securing them, because the 2.10.1-RC1 release date is very close, so we'd better have a 95% solution instead of keeping reflection thread-unsafe. Though here's the list of todo lazy vals for the reference: * BaseTypeSeq.maxDepth * WeakTypeTag.tpe * AnnotationInfo.forcedInfo For each of those lazy vals we need to make sure that their initializers never call back into themselves. Otherwise, there's a danger of a deadlock.
- Loading branch information...
Showing with 1,041 additions and 5 deletions.
Oops, something went wrong.