Revisiting default values

Peter Levart peter.levart at
Sun Aug 2 16:08:51 UTC 2020


On 7/28/20 9:06 PM, Brian Goetz wrote:
> I think what we need for Bucket 3 (which I think we agree is more 
> important than Bucket 2) is to (optionally, only for NGD inline 
> classes) restore parity with reference types by ensuring that the 
> receiver of a method invocation is never seen to be the default 
> value.  (We already do this for reference types; we NPE before the 
> dispatch would succeed.)   And the strategies we've been kicking 
> around have ranged from "try to prevent the default from showing up in 
> the heap" to "detect when the default shows at various times."
> If the important point in time is method dispatch, then we can 
> probably simplify to:
>  - Let some classes mark themselves as NGD (no good default)
>  - At the point of invocation of an NGD instance method, check the 
> receiver against the default, throw NPE if it is
>  - Optionally, try to optimize this check by identifying (manually or 
> automatically) a pivot field
> Note that even an unoptimized check is probably pretty fast already: 
> "are all the bits zero."  But we can probably often optimize down to a 
> single-word comparison to zero.
> Note too that we can implement this check in either generated bytecode 
> or in the VM; the semantics are the same, the latter is more secure. 

I can understand that automatic runtime prevention of invoking instance 
methods with default (all zero) object is important for fail-fast 
behavior. It is almost like invoking methods with identity typed 
parameters where null values are not valid parameters. We use 
Objects.requireNonNull() to check for such parameters at the beginning 
of such methods. So NGD classes could be designed such that they 
encapsulate all fields and explicitly check for absence of all-zero 
"this" value at the beginning of methods.
People want to simplify such tedious repetitive coding so they make 
frameworks that turn @NonNull annotations on method parameters into 
non-null checks at the top of the method. I can imagine a javac plugin 
could insert checks in all (non-private only?) instance methods when an 
inline class is marked with @NGD for example. Or this could be baked 
into Java language. In either case I think it is a matter of the inline 
class bytecode and not the code doing invocation (the call site). So it 
is safe by itself. Or am I missing something?

Regards, Peter

More information about the valhalla-spec-observers mailing list