Any::isNull check

Vitaly Davidovich vitalyd at gmail.com
Wed Dec 16 16:31:02 UTC 2015


>
> 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.  I'd think that's clearer and
cleaner than having one big method with large chunks of code applicable to
just ref or value type.

If you mean that the static compiler should generate two separate versions
> based on a single source representation of the code, you are gaining the
> small optimization of early localized dead-code-elimination at the cost of
> more duplication.  Maybe that's "right", maybe that's foolish.


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.


On Wed, Dec 16, 2015 at 11:04 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

>
>
> On 12/16/2015 10:52 AM, Vitaly Davidovich wrote:
>
> If you're working with an any-T, you don't know whether its a reference or
>> value.  So you still have to worry about NPE.
>
>
> Wouldn't the "right" thing to do, then, be specialize the method in
> question for ref vs value types differently? You'd then also ensure the
> dead code for value types wouldn't be in the bytecode as well.
>
>
> Depends what you mean by "right", and depends who is the implicit subject
> of the sentence.
>
> 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.)
>
> If you mean that the static compiler should generate two separate versions
> based on a single source representation of the code, you are gaining the
> small optimization of early localized dead-code-elimination at the cost of
> more duplication.  Maybe that's "right", maybe that's foolish.
>


More information about the valhalla-dev mailing list