deduplicating lambda methods

[Maurizio Cimadamore]

Hit 'Send' too fast - I have only one small comment:

I see that the dedup logic is disabled for serializable lambdas and also 
when debugging options are present. As you said, there are some tests 
that rely on certain bytecode shape, so in such case it might be handy 
to switch off the machinery entirely; rather than switching off the 
machinery by using '-g' (which could result in potentially other 
bytecode changes), I guess I'd prefer to have an escape hatch hidden 
flag we could use to shut down the dedup machinery entirely, without 
altering any other javac codegen behavior. This could be useful as a 
conservative prevention measures in build systems (e.g. JDK itself).

Maurizio


On 27/03/18 11:12, 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.
>