-
Type:
Enhancement
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: 26
-
Component/s: specification
Historically, it has been possible to perform 'acmp' on an 'uninitialized' object. This is almost always useless: the result is typically 'true' for matching 'uninitialized' types, and 'false' otherwise.
(Exception: some complex control flow *could* end up producing two different objects with the same 'new' instruction, and then make it statically impossible to tell whether two maching 'unitialized(nn)' types are equal. This is very unlikely to come up in practice.)
It has also been possible to perform 'ifnull'/'ifnonnull' on an 'uninitialized' object. The object is guaranteed to be non-null, so this instruction can always be simplified to a 'nop' or 'goto'.
We propose removing these degrees of freedom to simplify the set of operations that need to be supported by an 'uninitialized' object. (Future work, e.g. with value objects, will benefit from this simplification.)
(Exception: some complex control flow *could* end up producing two different objects with the same 'new' instruction, and then make it statically impossible to tell whether two maching 'unitialized(nn)' types are equal. This is very unlikely to come up in practice.)
It has also been possible to perform 'ifnull'/'ifnonnull' on an 'uninitialized' object. The object is guaranteed to be non-null, so this instruction can always be simplified to a 'nop' or 'goto'.
We propose removing these degrees of freedom to simplify the set of operations that need to be supported by an 'uninitialized' object. (Future work, e.g. with value objects, will benefit from this simplification.)
- relates to
-
JDK-8375481 4.10.1.4: set flagThisUninit whenever uninitializedThis is on the stack
-
- Open
-
-
JDK-8376521 Verifier: disallow acmp & ifnull on 'uninitialized' types
-
- Open
-
-
JDK-8375773 [lworld] JCK vm/instr tests fail due to incorrect verifier behavior for pre-Valhalla class file versions
-
- Open
-