a patch for new default methods in Map + more

[Vitaly Davidovich]

I was referring to the hardware branch predictor, which (in our case of
never seeing a null) will always predict correctly and not impede the
execution pipeline.  Even if code is generated for handling a null value
but then jumped over, the icache should prevent noticeable penalty.

Sent from my phone
On Jan 4, 2013 5:12 PM, "Remi Forax" <forax at univ-mlv.fr> wrote:

> 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<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
>>
>>
>>
>