diff options
author | Eugene Burmako <xeno.by@gmail.com> | 2013-02-02 00:27:38 +0100 |
---|---|---|
committer | Eugene Burmako <xeno.by@gmail.com> | 2013-02-11 19:18:28 +0100 |
commit | bebd62d5665b9166c1a44b3bcdc01287220a30b7 (patch) | |
tree | 6b66cb3b7019c31dd707d472d0d9d589833f8cbd /test/files/run | |
parent | 735634f1d634d2d6a2f8ed44f2e6185adc46c695 (diff) | |
download | scala-bebd62d5665b9166c1a44b3bcdc01287220a30b7.tar.gz scala-bebd62d5665b9166c1a44b3bcdc01287220a30b7.tar.bz2 scala-bebd62d5665b9166c1a44b3bcdc01287220a30b7.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.
in runtime reflection can undergo is init. #3 is dangerous and needs protection
Diffstat (limited to 'test/files/run')
0 files changed, 0 insertions, 0 deletions