Fwd: Comment on "Revisiting default values"

[Brian Goetz]

Received on the -comments list.

The optimization you describe here is what we have been referring to as 
using a "pivot field"; in some cases, you can strength-reduce the "are 
all fields the default" to a simpler "is this field the default" test.  
The trick is identifying the pivot field.  There are two broad approaches:

  - Ask the programmer to nominate it.
  - Figure it out.

The former has a terrible return-on-syntax; this is a micro-targeted 
feature that serves only as a hint to the optimizer.  This seems way 
below the threshold for a language feature (and, before anyone suggests 
"annotation", remember that annotations cannot drive language semantics.)

The latter is possible; we'd have to detect that all constructors assign 
some specific field to a non-default value.  (This could be done either 
by the static or dynamic compilers.)  But, given that most constructor 
assignments are some form of

     this.x = x

where x is a parameter, we can't (without global analysis) determine if 
x is a non-default value.  So the only realistic patterns we could key 
off of are:

     this.x = new Foo()  // new never evaluates to null

or

     if (x == null) throw;   // more generally, the default value for 
the type of x
     this.x = x;

While we can of course do this, it's not clear how effective this will 
be for typical primitive classes.  Which is to say, its an optimization, 
sometimes it will work, but it won't make the costs go away in general.



-------- Forwarded Message --------
Subject: 	Comment on "Revisiting default values"
Date: 	Mon, 29 Mar 2021 22:55:05 +0200
From: 	Raffaello Giulietti <raffaello.giulietti at gmail.com>
To: 	valhalla-spec-comments at openjdk.java.net



Hello,

IMO the "zero means null" proposal in [1] for instances implementing 
NoGoodDefault is the most consistent with the usual way of thinking Java.

Here's a possible way to slightly lower the cost of the check against 
the default (the "zero").

Of course, a default-hostile class always has proper instances in which 
at least one field (not necessarily the same in all instances) is "nonzero".

Oftentimes, by design, a class mandates some specific field to be 
"nonzero" in every instance. For example, the month (or the day) in 
LocalDate should not be zero; name or type in DirectMethodHandleDescImpl 
must be non-null; e0 in List12 must not be null; etc.

In such cases, once migrated to NoGoodDefault primitive classes, it 
suffices to check any of these fields for "zero" to witness the default 
value. That is, if such a field is "zero" then the instance is 
necessarily the unacceptable default. There's no need to compare all 
bits against "zero".

If the user could annotate such fields with something like @NonDefault 
or @DefaultWitness, the vm could possibly perform better in some 
circumstances, particularly on "fat" instances.


Greetings
Raffaello

----

[1] 
https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2021-March/001486.html