Travis hosed yet again, still waiting for pull of PRs #227 and #239, looking to implement weak memory-aware read/writes

Andrew Dinn adinn at redhat.com
Thu Jul 20 16:09:35 UTC 2017


The Travis build is bust again -- I think because JDK9 has now moved on
to release 178.

I have rebased PRs #227 and 239 against the latest master. I also
tweaked them to use JDK9 b178. I am still waiting for a review for #227
after over a month and still waiting for #239 to be pulled. Is there any
chance of this progressing soon? It would be helpful not to have to keep
updating the branches to cope with upstream changes and disappearing
JDK9 releases.

By the by, I'll mention that I have a patch ready to wrap up and push
which will make AArch64 use slightly weaker dmb barrier arguments than
it currently does where that is appropriate. It currently uses dmb ish
for all memory barriers but there are places where it could use dmb
ishst or dmb ishld.

I have not yet attempted to push this change because I am currently
working on providing a better patch which will replace Read and Write
nodes for volatile writes on AArch4 (either pucker volatile field
loads/stores or loads/stores which are inserted via Unsafe calls) with
variants that can profit from use of store release and load acquire
instructions (stlr/ldar). The patch will also need to replace any
associated Membar nodes with variants that not generate memory barrier
(dmb) instructions. This is arguably the most important outstanding fix
so far to bring Graal up to par with C2 on AArch64.

It would be very helpful to have the other patches out of the way before
integrating the load acquire/store release one. In particular, this
patch is not really independent of the ZeroExtend/SignExtend patch since
both of them require substituting the existing Read/Write with
AArch64-specific variants.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


More information about the graal-dev mailing list