Re: Question on layer/peeling

[Timo Kinnunen]

Before assigning semantics to x == null, let’s not forget boxing. What will happen if x is a boxed value which was returned from a call to the non-specialized Map.get(Object key) method?









-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Brian Goetz
Sent: ‎Tuesday‎, ‎January‎ ‎6‎, ‎2015 ‎21‎:‎52
To: Michael Barker, John Rose
Cc: valhalla-dev at openjdk.java.net





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.