a patch for new default methods in Map + more

Vitaly Davidovich vitalyd at gmail.com
Fri Jan 4 11:32:28 PST 2013


Also, null check is really cheap - 1 cycle with a perfectly predicted
branch, I doubt it will make any noticeable diff even if it stays.

Sent from my phone
On Jan 4, 2013 2:30 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> Once compiler kicks in and inlines (I'm assuming it will) Objects.equals,
> shouldn't the profile information get propagated into the caller? Avoiding
> small util methods just to preserve profile info would imply that the
> compiler is suboptimal, no?
>
> Sent from my phone
> On Jan 4, 2013 2:11 PM, "Remi Forax" <forax at univ-mlv.fr> wrote:
>
>> On 01/04/2013 07:09 PM, Doug Lea wrote:
>> > On 01/04/13 12:11, Peter Levart wrote:
>> >> Hi,
>> >>
>> >> I propose a patch for some new default methods in j.u.Map and some
>> more:
>> >>
>> >> http://dl.dropbox.com/u/101777488/jdk8-lambda/Map/webrev.02/index.html
>> >>
>> > Thanks for redoing these as a webrev!
>>
>> Peter, you should not add Objects.equals() here, you can use it if you
>> know that a key will be null,
>> but not if you don't know. You have to write the null check in the
>> method and let the VM do the profiling.
>> With that, users that never use a HashMap with null key may not pay the
>> extra cost of the null check.
>> If you use Objects.equals, because it will be also used in a method with
>> a value that is null, the VM will always do the check.
>>
>> Rémi
>>
>>
>>


More information about the lambda-dev mailing list