On 12/01/2014 05:58 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057020
There are 2 major LambdaForm caches: LambdaFormEditor-based and
MethodTypeForm. The former is per-LambdaForm and the latter is per
method type erased to basic types. The problem is that these caches
don't support eviction, so they can hold LambdaForms forever.
Usually, it's not a problem since an application has very limited
number of unique erased method types (e.g. on Octane/Nashorn it varies
1,5-3k shapes).
The fix is to use SoftReferences to keep LambdaForms alive as long as
possible, but avoid throwing OOME until the caches are evicted. I
experimented with WeakReferences, but it doesn't hold LambdaForms for
long enough: LambdaForm cache hit rate degrades significantly and it
negatively affects application startup and warmup, since every
instantiated LambdaForm is precompiled to bytecode before usage.
Testing: jdk/java/lang/invoke/LFCache in stress mode + jck
(api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams,
octane
Thanks!
Best regards,
Vladimir Ivanov
Hi Vladimir,
So WeakReferences did not hold LambdaForms long enough even with strong
back-reference from LambdaForm to the lambda form 'this' was derived
from? So final derived LambdaForms (leaves) are not kept referenced from
the code? Or did back-references keep intermediate LambdaForms in cache
for too long (forever?) and you wanted them to be evicted too?
Regards, Peter
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
