deduplicating lambda methods

[B. Blaser]

On 28 March 2018 at 20:09, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
>
> On 28/03/18 18:58, B. Blaser wrote:
>>
>> On 28 March 2018 at 19:44, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>>
>>> Uhm - seems to me that the currently implemented logic is more subtle
>>> than
>>> comparing symbols by name in the visitIdent case? E.g. it (correctly)
>>> uses
>>> information about the relative position of a lambda parameter in the
>>> parameter list and compares that instead of names. And visitSelect is
>>> correctly doing a == on the accessed symbol, so that
>>>
>>> class Foo { String x; }
>>>
>>>
>>> (Foo a) -> a.x
>>>
>>> (Foo b) -> b.x
>>>
>>> are deemed equal because:
>>>
>>> (i) - a and b have same positional info
>>> (ii) - a.x and b.x refer to the same (==) symbol (Foo::x)
>>
>> I missed this e-mail but I just sent 5 minutes ago the full patch
>> which preserve relative positions of lambda parameters, of course.
>> If you try the two examples I sent previously without the patch,
>> you'll see that:
>>        r1 = () -> {
>>            Class<?> c = Integer.class;
>>        };
>>
>> isn't de-duplicated because occurrences of Integer.class aren't '==' and:
>>
>>        r1 = () -> {
>>            Runnable r2 = () -> {};
>>        };
>>
>> isn't de-duplicated because calls to lambda meta-factory aren't '=='.
>
> To me this seems to suggest that, if we want to get better results out of
> the dedup machinery, we have to up our lowering game, so that we don't do
> excessive generation of fresh symbols. Right now we don't cache .class
> symbols and also metafactory calls with same static args and BSM - and
> that's the problem you are seeing, I believe.

Note that the fix I suggest also addresses local variable symbols
which aren't '=='.

Bernard

> Maurizio
>
>>
>> Bernard
>>
>>> Maurizio