deduplicating lambda methods
maurizio.cimadamore at oracle.com
Tue Mar 27 10:16:58 UTC 2018
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).
On 27/03/18 11:12, Maurizio Cimadamore wrote:
> This looks good to me.
> Great job!
> 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>
>>> looks good!
>>> 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:
>> 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
>> * I fixed CheckExamples to handle the 'note' diagnostic that was
>> added to
>> * 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.
More information about the amber-dev