deduplicating lambda methods

Maurizio Cimadamore maurizio.cimadamore at
Tue Mar 27 22:46:13 UTC 2018

Right - I think the current mix of option is fine. If people want t use 
debugging info, they get that with -g, as the dedup machinery is 
disabled. But in extreme cases where dedup can't be used, and neither 
can -g (e.g. in tests that are sensitive to bytecode changes), there's 
an escape hatch. Since it's an escape hatch, I don't think it deserves 
more than an hidden flag.


On 27/03/18 19:54, Liam Miller-Cushon wrote:
> On Tue, Mar 27, 2018 at 11:43 AM Vicente Romero 
> <vicente.romero at <mailto:vicente.romero at>> wrote:
>     >>> I believe --debug options are used to generate extra
>     information out of
>     >>> javac, not to alter its behavior - it's probably better to use
>     an hidden
>     >>> flag (e.g. -XDdeduplicateLambdas=...) - which is consistent to
>     what we have
>     >>> done for indy string concat.
>     >>>
>     >> I will introduce this change before pushing the patch,
>     > Should this option really be hidden? It's currently necessary to
>     > disable de-duplication when debugging to preserve all LNT/LVT.
>     > Of course, this could be a '-X...' instead of '-g' but
>     documented, I think.
>     > Note that de-duplication doesn't really alter javac behavior;
>     let say
>     > 'in reverse' that lambda *duplication* would be an additional debug
>     > information...
>     err, I think you have a good point. I have already pushed the
>     patch to:
>, but we can still rework the option
> To make sure we're all on the same page, the feature is unconditionally
> disabled if -g or -g:{lines,vars} is passed, to ensure the LNT/LVT info is
> correct. The feature can also be disabled with -XDdeduplicateLambdas,
> but it isn't necessary to explicitly set that flag to preserve LNT/LVT 
> info.
> The logic for this is here:

More information about the amber-dev mailing list