Any::isNull check

[Vitaly Davidovich]

On Wednesday, December 16, 2015, Brian Goetz <brian.goetz at oracle.com> wrote:

> I think we're just spinning in "I could imagine ..." territory now.  Try
> porting a real codebase (like Collections) and I think your perspective
> will change.
>

Specialization has existed in other languages for more than a decade.
There's some imagination needed for the Java version but the general
principle of "how do I specialize/organize code paths specific to a certain
type or sets of types sharing common characteristics" is not new.

>
> On 12/16/2015 11:31 AM, Vitaly Davidovich wrote:
>
> If you mean that the developers should write two versions of each method,
>> one for nullable and one for not, that would be ridiculous.  Duplicating N
>> lines of code because one line of a method has to do a null check would be
>> terrible.  (Spend a half hour trying to port the Collections code with that
>> approach, and ask yourself if you can honestly ask people to code that
>> way.)
>
>
> Not of each method.  In Paul's case he made it sound like there's some
> substantial dead code to be eliminated in case of value types, making it
> sound like there's more than just one or two lines of difference.  The
> other approach is to take the one or two lines in a bigger method that
> differ for value vs ref type and move just them into 2 specialized methods,
> one for ref and other for value types.
>
> You mean, like the Any.isNull() method Paul was asking about?
>

Paul's question wasn't about the method but rather the code it guards.


>
>
> This solution sounds appealing until you try it.  Asking people to split
> out tiny peeled methods sounds unintrusive.  In the first 30 seconds, it
> even feels clever.  Thereafter, it feels burdensome.
>

Is the concept burdensome or the syntax? I don't think the concept is
burdensome as the code is dealing with fundamentally different types.  The
question is how do you write a generic method where some code paths are
applicable for value and other for reference types; do you bulk it all up
into one method with type guards or split it into separate distinct pieces
entirely.  Besides the byte code size implications I personally find
splitting into distinct units more sound and easier to follow.  I realize
this is subjective though.


>
>
> Given current limitations in inlining heuristics, removing dead bytecode
> outright before JIT sees it is a big win.  Right now, lots of people end up
> splitting methods in awkward unnatural ways just to avoid hitting these
> issues.
>
>
> When you say "people", be aware you really mean "the 0.001% of users for
> whom it makes a big enough difference to put up with it" (as this is the
> world you live in.)  I care about those people too, but I care more about
> the code written by the other 99.999% of Java programmers.  So, I'm
> focusing first on "what's the right expression of the code" and then
> "what's the right classfile representation".
>
> Going back to work now.
>
>
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! 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.




-- 
Sent from my phone