diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2015-05-16 21:02:56 +1000 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2015-05-18 09:07:54 +1000 |
commit | 1d8c63277e97c57e12fa9864a2d238d4f54c10f0 (patch) | |
tree | 949d2125c97a74bdc0eee5d581684ff93f1f1a77 /test/files/specialized/tb3651.scala | |
parent | afa2ff9f76123ab982dc5bb2f1110bb58e75c68c (diff) | |
download | scala-1d8c63277e97c57e12fa9864a2d238d4f54c10f0.tar.gz scala-1d8c63277e97c57e12fa9864a2d238d4f54c10f0.tar.bz2 scala-1d8c63277e97c57e12fa9864a2d238d4f54c10f0.zip |
[indylambda] Enable caching for lambda deserialization
We add a static field to each class that defines lambdas that
will hold a `ju.Map[String, MethodHandle]` to cache references to
the constructors of the classes originally created by
`LambdaMetafactory`.
The cache is initially null, and created on the first deserialization.
In case of a race between two threads deserializing the first
lambda hosted by a class, the last one to finish will clobber
the one-element cache of the first.
This lack of strong guarantees mirrors the current policy in
`LambdaDeserializer`.
We should consider whether to strengthen the combinaed guarantee here.
A useful benchmark would be those of the invokedynamic instruction,
which allows multiple threads to call the boostrap method in parallel,
but guarantees that if that happens, the results of all but one will
be discarded:
> If several threads simultaneously execute the bootstrap method for
> the same dynamic call site, the Java Virtual Machine must choose
> one returned call site object and install it visibly to all threads.
We could meet this guarantee easily, albeit excessively, by
synchronizing `$deserializeLambda$`. But a more fine grained
approach is possible and desirable.
A test is included that shows we are able to garbage collect
classloaders of classes that have hosted lambda deserialization.
Diffstat (limited to 'test/files/specialized/tb3651.scala')
0 files changed, 0 insertions, 0 deletions