diff options
author | Eugene Burmako <xeno.by@gmail.com> | 2013-02-02 00:27:38 +0100 |
---|---|---|
committer | Eugene Burmako <xeno.by@gmail.com> | 2013-10-18 17:48:51 +0200 |
commit | d05566ca327103d61b071a5022be98f1f3f045f3 (patch) | |
tree | 6023560ed3c69d52996bf16c652b3baf7247ed63 /test/files/run/t153.check | |
parent | 484d6d70a4c51d0ddf220c67265182949e69ca45 (diff) | |
download | scala-d05566ca327103d61b071a5022be98f1f3f045f3.tar.gz scala-d05566ca327103d61b071a5022be98f1f3f045f3.tar.bz2 scala-d05566ca327103d61b071a5022be98f1f3f045f3.zip |
optimizes Scala reflection GIL
First of all, GIL should only apply to runtime reflection, because noone
is going to run toolboxes in multiple threads: a) that's impossible, b/c
the compiler isn't thread safe, b) ToolBox api prevents that.
Secondly, the only things in symbols which require synchronization are:
1) info/validTo (completers aren't thread-safe),
2) rawInfo and its dependencies (it shares a mutable field with info)
3) non-trivial caches like in typeAsMemberOfLock
If you think about it, other things like sourceModule or associatedFile
don't need synchronization, because they are either set up when a symbol
is created or cloned or when it's completed. The former is obviously safe,
while the latter is safe as well, because before acquiring init-dependent
state of symbols, the compiler calls `initialize`, which is synchronized.
We can say that symbols can be in four possible states: 1) being created,
2) created, but not yet initialized, 3) initializing, 4) initialized.
Of those only #3 is dangerous and needs protection, which is what this
commit does.
Diffstat (limited to 'test/files/run/t153.check')
0 files changed, 0 insertions, 0 deletions