Advice on finding out the cause of test failure of VarHandleTestAccessBoolean on windows x64

[John Rose]

On Aug 12, 2016, at 8:36 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please can someone help/advice how to find the cause of a test failure i am observing.

It might be a failure of alias analysis.  The T_BOOLEAN unsafe access, when applied to
a real boolean field of a class, can weaken to the same code as a getfield or putfield.
A later getfield can "see" the most recent matching getfield or putfield, whether it is
a bytecode or a successfully weakened unsafe access.

But the CAS address probably won't weaken to a field address, either because CAS
is complicated (doesn't match a get/set bytecode semantics) or because T_BYTE doesn't
match T_BOOLEAN.  In that case, maybe the JIT is pulling the previously read T_BOOLEAN
access across the T_BYTE access, on the grounds that the T_BYTE access cannot alias.

If all this is true, we have a C2 issue related to mismatched loads and stores.

Possible test for hypothesis:  Obscure the offset portion of the boolean field, in the test
code (run it through a volatile variable, or an all-constant array indexed by a random number).
See if the problem persists.  Of course, you'll detune the optimization in that case also,
which could mask the bug.  To do this you have to use raw unsafe, not a VH.  Could lead
(at least) to a good minimal reproducer.

I can think of several reasons why the above may *not* be your problem, but it's worth a look.
Maybe a kind C2 person can look into it?  (Someone who fixed the last store-mismatch bug? :-) )

VarHandles are throwing a lot of really new, cool code shapes into C2, which will lead to bugs
like this.  It's the same kind of bug we'll also see with more aggressive use of pointer reshaping
by Panama APIs.  (E.g., a "struct stat" stashed in a Java long[] in the heap.)

— John