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

[Tom Rodriguez]

Andrew Dinn wrote:
> 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.

Sorry I didn't push 239 last week but we had a little release emergency. 
  Both 239 and 227 are now in our internal gate and should push today. 
Sorry for the delay.

>
> 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.

Would we in general be better off having a VolatileReadNode and a 
VolatileWriteNode that includes the required barriers instead of 
prebarrier/read|write/postbarrier?  That would make this kind of thing 
more of a backend decision. Or do you need to look at nearby barriers 
anyway to produce the best code?

tom

>
> 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