Any::isNull check

[Vitaly Davidovich]

>
> Yes.  JDK developers have to, and are willing to, code in ways we're not
> willing to ask other people to code.  We're fully aware of the need to make
> these things *possible*.  But we're also quite aware of what it is, and
> isn't, reasonable to ask of developers in terms of how regular developers
> write their code.  And we are for sure not going to let micro-performance
> issues like this drive how the majority of users are expected to code.


The conversation was really about how to organize chunks of code dealing
with ref vs value types; I mentioned the bytecode size implications of big
methods on inlining as a secondary effect.  Taking performance out of the
equation, some "regular" Java developers will like to split their value vs
ref type code blocks into separate methods; others may like to have one big
method with Any.isNull(or whatever syntax will be) guards.  Didn't Paul
have a thread about that a few days ago?  So either way I suspect you won't
please everyone anyway, at which point, if you're going to choose one
approach vs the other you may as well take the one with some side
performance benefit.

I'd also argue that inlining is not a micro optimization for Java -- the
entire performance model is predicated on this happening in the right
places.  Anything that somehow upsets that fragile beast or worsens the
situation will not be well-received.  Anyway, I'll punt on further
performance discussion at this point.


> So, can we please go back to work now?


Yes :)

On Wed, Dec 16, 2015 at 1:05 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I really dislike this percentile breakdown that you've mentioned several
>> times on this list.  JDK core libs developers themselves have to deal with
>> this, and that code is used by many people with some expectation of
>> performance.  The whole value type project is performance geared!
>>
>
> Yes.  JDK developers have to, and are willing to, code in ways we're not
> willing to ask other people to code.  We're fully aware of the need to make
> these things *possible*.  But we're also quite aware of what it is, and
> isn't, reasonable to ask of developers in terms of how regular developers
> write their code.  And we are for sure not going to let micro-performance
> issues like this drive how the majority of users are expected to code.
>
> Moreover, nobody is suggesting some sharp tool be added only for experts.
>> I'm simply saying that given the choice of presenting more byte code vs
>> less makes a difference.  If there's a reasonable way to present less it's
>> a win.  Saying JIT is really good at eliminating dead code is, while true,
>> not the full picture when the topic is performance.
>>
>
> Performance is not the full picture either.
>
> Quite honestly, at this point, micro-performance issues like this should
> not even be part of the discussion at all.  We are well aware of the
> performance tradeoffs that await us in the event we actually get to a model
> that we think is good enough to foist on Java users. But its simply way too
> early to deep-dive on micro-performance issues like this -- while this will
> eventually be important, at this early stage, its a distraction.
>
> So, can we please go back to work now?
>
>
>