RFR (S) JDK-8223017: [lworld] checkcast/instance broken for LW2 arrays
david.simms at oracle.com
Fri May 3 14:35:35 UTC 2019
Updated webrev: http://cr.openjdk.java.net/~dsimms/valhalla/8223017/
Remove "QDescBit" constant pool tag encoding for arrays of Q, it wasn't
required. Since I was there I removed macro and renamed to
"JVM_CONSTANT_QDescBit" in-line with the rest of the code...sorry for
the extra noise in the patch.
On 30/04/19 3:46 PM, David Simms wrote:
> Nice spotting, I didn't differentiate the "checkcast" behavior for
> "Q-type descriptors" and "Array Q-type descriptors".
> Since we are heading into a local holiday (tonight and tomorrow,
> bonfire night), I'll leave a note on my thinking here if I don't get
> to it until Thursday...
> * I probably need to || in another bit for arrays of q-type in the
> constant pool tag for the difference in behavior. Thinking of
> using "JVM_CONSTANT_Unicode" since it is unused (further mess,
> but there are not separate bits left)
> * anewarray and multianewarray needs something to tell them it's a
> q-type array, but for the interpreter at least we jump into the
> VM...so I wonder if we need the constant tag encoding at all
> Will look a little further into this...
> On 30/04/19 12:27 PM, Tobias Hartmann wrote:
>> Hi Mr. Simms,
>> I'm seeing the following inconsistent behavior:
>> MyValue1? va1 = (MyValue1?)null; // does not throw NPE
>> MyValue1? va2 = null; // does not throw NPE
>> MyValue1 va3 = null; // does not throw NPE
>> MyValue1 va4 = (MyValue1)null; // throws NPE
>> On 29.04.19 12:01, David Simms wrote:
>>> Here's a fix for the missing super type relationship for null-free
>>> arrays, i.e. "[QFoo;" <:
>>> "[LFoo;"...once LW2 array support went in, it accidentally skipped
>>> it's null-allow type and went
>>> straight to Object...added a few more test cases.
More information about the valhalla-dev