deduplicating lambda methods

[Vicente Romero]

Hi,

Attached there is a patch, as in hack-ish, quick, use with care, to be 
applied on top of last Liam's patch that considers constant values in 
the trees. This patch allows to deduplicate lambdas like:

Function<Integer, Integer> l1 = i -> 2 + 3;    and:
Function<Integer, Integer> l2 = i -> 5;


Thanks,
Vicente

On 03/17/2018 03:10 PM, Vicente Romero wrote:
>
>
> On 03/17/2018 03:00 PM, Brian Goetz wrote:
>>
>>
>>>> I don't think we want to be duplicating the constant folding logic 
>>>> in multiple places, but I also don't think we have to -- doesn't 
>>>> L2M run after constant folding already?  I ask because I've already 
>>>> seen constant propagation turn capturing lambdas into noncapturing.
>>>
>>> I don't think we need to duplicate the constant folding logic for 
>>> this, I just think that the hasher and the differ should be blind 
>>> regarding the substructure of a tree as soon as a constant is found, 
>>> be it in a variable or as the constant value of a tree. Liam has a 
>>> good point, if our new constant folding phase were rewriting the 
>>> trees then the differ and the hasher he is proposing would have this 
>>> for free. I guess that this is a use case that can make us consider 
>>> doing tree rewriting as part of the new constant folding phase, but 
>>> we are not doing it right now, only for some trees: basically ldc() 
>>> indy() and condys. That's why I was saying that considering 
>>> constants in the tree differ / hasher could wait and that it don't 
>>> have to be part of this patch.
>>>
>>
>> When you say blind, obviously it has to take the constants into account, 
>
> right but it doesn't have to redo what constant folding is doing, the 
> constant will be already there sitting in the tree,
>
>> since x -> x+2 and x->x+3 are different lambdas.  I think for now, 
>> not trying to do anything special here is the right move;
>
> I totally agree that's why I started saying that this could be a 
> follow-up development
>
>> this could conceivably fail to deduplicate x -> x + 2  and x -> x + 
>> TWO  when TWO is a static final, but that's an acceptable loss, since 
>> deduplication is merely optimistic.
>
> right it would fail to do that, but it could probably handle it by 
> adding a couple of LOC more compared to the current patch, but again 
> I'm not proposing to do it now
>
>>
>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: considering.constants.patch
Type: text/x-patch
Size: 1878 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/amber-dev/attachments/20180317/98df20da/considering.constants.patch>