RFR(S): 8140390: Char stores/loads accessing byte arrays must be marked as unmatched
tobias.hartmann at oracle.com
Fri Nov 20 08:54:22 UTC 2015
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:
>> That looks good to me.
> 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.
More information about the hotspot-compiler-dev