Peter, thank you very much for experimenting with that!
It looks really promising. I do believe we need to purge LambdaForm
cache, until there's no upper limit on a possible number of LambdaForm
instance.
I'll gather some data how efficient a cache with weak keys is and get
back to you.
Best regards,
Vladimir Ivanov
On 9/10/14, 7:30 PM, Peter Levart wrote:
On 09/03/2014 03:29 PM, Vladimir Ivanov wrote:
Peter,
Yes, it's a known problem [1].
There are other caches (in MethodTypeForm, for example), which
shouldn't retain their elements.
Hi Vladimir,
I was tempted to see what it would take to use weakly referenced
LambdaForms from cache entries (LambdaFormEditor.Transform objects).
This is what I came up with:
http://cr.openjdk.java.net/~plevart/misc/LambdaFormEditor.WeakCache/webrev.01/
In this modification on top of your patch, a reference to LambdaForm
from Transform is not a final field any more (WeakReference has a normal
field), so I had to change LambdaForm.transformCacheto be volatile field
to enable safe publication of Transform objects and transiently
LambdaForm objects. I also used ordered writes with volatile reads for
Transform[] array elements where necessary. CHM already does what's
necessary. If LambdaForm objects are unsafe-publication-tolerable, this
can be simplified.
I have made a little effort to re-use slots occupied by cleared
Transform objects, but nothing fancy like using ReferenceQueue(s) or
such, since there would have to be a queue per LambdaForm and this would
bring some overhead with it. Transform objects are very compact (even
when they extend a WeakReference) and majority of heap is released by
free-ing weakly reachable LambdaForm objects which can be quite big and
deep sometimes.
A cache forms a tree of LambdaForm objects. Child LFs are derived from
base (parent) LFs. parent -> child references are weak, but I added
child -> parent references which are strong. If there is a strong
reference to some cached LF from the application, the whole path leading
from the root LF to the cached LF is kept alive this way, so that any
code that wishes to follow that path can get to the cached LF.
So do you think that cached LambdaForm(s) are so general that they are
better cached for the life of JVM even in long-running application
servers that re-deploy apps on the fly and using WeakReference(s) is not
necessary?
Regards, Peter
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8057020
On 9/3/14, 3:43 PM, Peter Levart wrote:
Hi Vladimir,
I'm sure you and John have thought about it through, but I'll ask
anyway. Are cached LambdaForms going to stay around forever? What about
using a WeakReference<LambdaForm> (LambdaFormEditor.Transform could
extend WeakReference). This way unused LambdaForms would get GCed.
Regards, Peter
On 09/02/2014 03:59 PM, Vladimir Ivanov wrote:
Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00
Best regards,
Vladimir Ivanov
On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
https://bugs.openjdk.java.net/browse/JDK-8057042
LambdaFormEditor provides an API to transform LambdaForms. Deriving
new
LambdaForms from a base one allows to cache and reuse results of
repeated transformations.
BMH binding is rewritten to use LambdaFormEditor.
Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn,
octane w/
"-ea -esa" and COMPILE_THRESHOLD={0,30}.
Reviewed-by: vlivanov, ?
Contributed-by: john.r.r...@oracle.com
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
