deduplicating lambda methods

[Vicente Romero]

On 03/27/2018 10:17 AM, Brian Goetz wrote:
> Yes, I think this is ready to say we're done with development on this 
> and move towards testing and integration (modulo the improvements 
> suggested in review.)

I'm running a mach5 job previous to pushing the patch, so that we cover 
closed repo tests too

>   We'll take the patch and re-run the stats on the JDK to see where 
> there was duplication; I don't expect a lot as most the JDK codebase 
> has been slow to adopt lambdas for various reasons.  I'll post the 
> results here.

I'm running the stats, will send the results soon

>
> I'm more interested in the impact on the Google codebase, both the 
> fraction of lambdas combined, as well as if there is any effect on 
> compilation performance.

yep, me too :)

Vicente
>
>
>
> On 3/27/2018 6:12 AM, Maurizio Cimadamore wrote:
>> This looks good to me.
>>
>> Great job!
>>
>> Maurizio
>>
>>
>> On 27/03/18 06:25, Liam Miller-Cushon wrote:
>>> On Mon, Mar 26, 2018 at 5:25 PM Vicente Romero 
>>> <vicente.romero at oracle.com>
>>> wrote:
>>>
>>>> looks good!
>>>>
>>> thanks!
>>>
>>>
>>>> one minor comment:
>>>>
>>> oops, thanks for the catch. Fixed.
>>>
>>> I made a few more small changes since the last webrev:
>>> * There were some failing javac tests:
>>> annotations/typeAnnotations/classfile/InstanceInitializer,
>>> annotations/typeAnnotations/classfile/StaticInitializer,
>>> classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest. The output
>>> looks correct, but the lambda deduplication broke some assertions 
>>> about the
>>> expected bytecode. I added a flag to those tests to disable the 
>>> feature for
>>> now.
>>> * I fixed CheckExamples to handle the 'note' diagnostic that was 
>>> added to
>>> LambdaToMethod.
>>> * I fixed a bug in TreeDiffer involving incorrectly recursing into the
>>> target of break and continue statements, and added another test case.
>>>
>>> The tier1 tests are all passing now, and the changeset is attached.
>>
>