[9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

[Peter Levart]

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.rose at oracle.com
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>