Question on layer/peeling

[Brian Goetz]

Some sort of T.null / T.default / default(T) is easy and generally seems 
a no-brainer, just haven't implemented it yet.

Assigning semantics to x == null is a nice idea and would indeed reduce 
the work of anyfication, which is good.  It should be trivial, but isn't 
quite.

There are two ways to represent this in bytecode:

     aload <my value>
     aconst_null
     if_acmpeq

and
     aload <my value>
     ifnull <target>

The latter is easy; replace "ifnull <target>" with "pop" (and "ifnonnull 
<target>" with "pop; goto <target>")  (And don't forget to use pop2 
instead if specializing to long or double.)

The former, however, is not quite as easy, since what's on the stack 
could have come from a much more complicated evaluation that leaves a 
null on the stack.  We'd have to ensure there was no way the former 
bytecode sequence got generated from javac.


On 1/6/2015 3:38 PM, Michael Barker wrote:
>     The trick can also be coaxed to give semi-plausible semantics to
>     seemingly bogus expressions like "x == null" or "x == (Object)y"
>     (for any x).  If "x" is a primitive, since autobox conversions never
>     produce "null", then "x == null" and "x == (Object)y" are
>     complicated ways of saying "false".  But this doesn't help with
>     nulling assignments like "a[i] = null"; there you need "T.null" (my
>     bikeshed preference to "default(T)").
>
>
> I think allowing x == null (always false) and a[i] = T.null for value
> types would certainly make the coding simpler as it would avoid layering
> for a number of very common cases.  In the null comparison case I would
> assume that Hotspot could easily throw away the condition altogether in
> the specialised class.