deduplicating lambda methods

Vicente Romero vicente.romero at oracle.com
Tue Mar 27 17:33:40 UTC 2018



On 03/27/2018 12:58 PM, Brian Goetz wrote:
> It looks like there were no changes in the outcome, perhaps because 
> there were no within-file duplications in the JDK.  (Which I 
> believe.)  A more streams/Rx/CompletableFuture-heavy codebase would 
> likely see an improvement.

right, no difference :(, let's see what happens with Liam's numbers :)

Vicente

>
> On 3/27/2018 11:19 AM, Vicente Romero wrote:
>> Hi,
>>
>> These are the stats after applying the lambda deduplication patch to 
>> the condy-folding repo. There are actually 2 results, first with no 
>> condy begin generated and the second with condy, for the sake of the 
>> comparison. I'm running an extra test with constant folding but I 
>> don't expect it to change the results.
>>
>> Thanks,
>> Vicente
>>
>> On 03/27/2018 10:42 AM, Vicente Romero wrote:
>>>
>>>
>>> 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.
>>>>>
>>>>
>>>
>>
>



More information about the amber-dev mailing list