deduplicating lambda methods

[Brian Goetz]

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



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