a patch for new default methods in Map + more

[Remi Forax]

On 01/04/2013 08:32 PM, Vitaly Davidovich wrote:
>
> 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.
>

because the profile is bloated, the information about the branch that 
should be taken is not accurate, the basic block for the value equals to 
null has be generated, so you may end up with a jump which is not more free

> Sent from my phone
>

Rémi

> On Jan 4, 2013 2:30 PM, "Vitaly Davidovich" <vitalyd at gmail.com 
> <mailto: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
>     <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
>
>