Execute read barrier for constrained TX within the GS event handler

[fjeremic]

We currently only take advantage of constrained transactions (TX) in
ConcurrentLinkedQueue methods we recognize. The problem for the
constrained TX is that the return address the hardware populates for us
in J9GSParameters.returnAddr points to the TBEGIC instruction
because the constrained transaction has no fall back path!

The very first thing we do inside of the transactions in the
ConcurrentLinkedQueue methods we recognize is load a field which
requires the read barrier. So the control flow ends up looping forever
failing on the read barrier in the TBEGIC region, then the handler
aborts the read barrier because we are in a TX and we loop again, etc.

This causes a hang in the JVM. There is another bit in J9GSParameters
which tells us whether the TX that triggered the guarded storage event
was constrained or not. Currently there are two read barriers in each
of the two methods we recognize and inline. The read barriers are both
of the form o.f.g i.e. two field indirections both requiring hardware
read barrier instructions. Given that if we reach the hardware read
barrier event handler the transaction would have already aborted there
should be no functional issue to executing the read barrier at that
point for either the read of f or g because the JIT has ensured
there are no side-effects (stores) before the hardware read barriers,
only after.

The fix here is to execute the read barriers for constrained
transactions but avoid executing them for non-constrained transactions
since we have a fall back path in that case.

Signed-off-by: Filip Jeremic fjeremic@ca.ibm.com

[fjeremic]

Leaving as WIP until I've done a bit more testing on my side. Should be ready for review however.

[joransiu]

LGTM

[fjeremic]

My testing has been complete. This PR should be ready to go @joransiu. Launching builds on your behalf.

Jenkins test sanity zlinux JDK8

[fjeremic]

This PR should be ready to go @joransiu.