Thanks, Paul!
Updated webrev in place.
On Dec 1, 2014, at 5:58 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com>
wrote:
http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057020
That LambdaFormEditor.putInCache method just got more gnarly :-)
Generally looks good.
In src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java
366 lambdaForm.transformCache = c = ta;
Do you need to set "c"? It's a local variable and by this point the method
should return rather than loop.
I did it mostly as a cleanup. Now I think that it doesn't help much.
Removed (+ similar change in another place).
In test/java/lang/invoke/LFCaching/LambdaFormTestCase.java
55 private static final List<GarbageCollectorMXBean> gcInfo;
56
57 private static long gcCount() {
58 return gcInfo.stream()
59 .map(GarbageCollectorMXBean::getCollectionCount)
60 .reduce(0L, Long::sum);
61 }
You can do:
gcInfo.stream().mapToLong(GarbageCollectorMXBean::getCollectionCount).sum();
Good point. Updated.
Best regards,
Vladimir Ivanov
Paul.
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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev