a patch for new default methods in Map + more

Remi Forax forax at univ-mlv.fr
Fri Jan 4 11:40:58 PST 2013


On 01/04/2013 08:30 PM, Vitaly Davidovich wrote:
>
> Once compiler kicks in and inlines (I'm assuming it will) 
> Objects.equals, shouldn't the profile information get propagated into 
> the caller?
>

yes, it's 'propagated back', but it's not the same profile because the 
profile is shared by all methods call Object.equals.

> Avoiding small util methods just to preserve profile info would imply 
> that the compiler is suboptimal, no?
>

yes, it's a kind of broken. Anyway, if a value can be null using 
Objects.equals is a good idea.

Rémi

> Sent from my phone
>
> On Jan 4, 2013 2:11 PM, "Remi Forax" <forax at univ-mlv.fr 
> <mailto: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