[9] RFR(S): 8140390: Char stores/loads accessing byte arrays must be marked as unmatched

Tobias Hartmann tobias.hartmann at oracle.com
Fri Nov 20 08:54:22 UTC 2015


Hi John,

thanks for the review.

On 19.11.2015 21:07, John Rose wrote:
> 
> On Nov 18, 2015, at 7:59 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>>
>>> http://cr.openjdk.java.net/~thartmann/8140390/webrev.00/
>>
>> That looks good to me.
>>
>> Roland.
> 
> 
> It looks good to me, too, but I'm not fully comfortable with three booleans in a row.
> The API is starting to look like a Turing Tape.  Let's file a cleanup bug on it,
> to collapse those three booleans into a single bitmask, with named components,
> something like LoadNode::ControlDependency.  (MemNode::Mismatch=4, etc.)

I agree that a bitmask would be better here. I filed JDK-8143385 to keep track of this.

> More substantively, Panama will eventually make mismatched accesses very
> common, as we overlay C-like data structures inside of byte[] and long[] carriers,
> or inside flat carrier objects (e.g., Long4 with fields long c0,c1,c2,c3).
> Have we got a robust solution to keep the memory references straight,
> when we are using C-like viewing casts on carrier bits?

I'm not sure about this. I think Vladimir I. is prototyping this at the moment.

Thanks,
Tobias


More information about the hotspot-compiler-dev mailing list