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

[Vladimir Ivanov]

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.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
>>>
>