a patch for new default methods in Map + more
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.
> 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:
> > 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.
More information about the lambda-dev