Question on layer/peeling
brian.goetz at oracle.com
Tue Jan 6 20:52:08 UTC 2015
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
There are two ways to represent this in bytecode:
aload <my value>
aload <my value>
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.
More information about the valhalla-dev