[aarch64-port-dev ] volatiles and membars in jdk7 aarch64.ad

[Andrew Dinn]

On 25/11/14 18:26, Andrew Haley wrote:
> This really is in flux at the moment.  I have a patch nearly ready
> which switches on the command line, so we can do some benchmarking.
> 
> I'd stay with separate barriers for now.

Ok, I'll wait for your update.

Regarding my question about shared code changes, when I looked deeper
into this check-in:

  7816 4ff9e02880b6 aph           [bugfix]
  C2: use store release instructions for all volatile stores. Remove
  leading and traililng barriers around volatile stores.

I realised that it contained all the shared code changes needed to make
the current volatile rules work (as well as the mods to those rules to
rely on is_unordered() and to employ load acquire/store relase where
appropriate).

I have not attempted to backport any of that changeset to
icedtea7-forest-aarch64 because I was sticking with separate barriers
until I knew what was involved.  Once you have posted a switchable
version and it has been tested I will backport the above change set and
the updates to make it switchable.

I was motivated to ask about this because I was wondering about the
effect on Ed's pipeline model of omitting the loadX_volatile or
StoreX_volatile rules. I think it probably works out ok. If separate
barriers are used then the model will account for a volatile memory
operation as two separate operations, a barrier employing
ins_pipe(pipe_serial) and a load or store using ins_pipe(iload_mem) or
ins_pipe(istore_mem). If the volatile operations are included then the
model accounts for a synchronizing memory operation as a single
acquiring load or releasing store using ins_pipe(pipe_serial) or
ins_pipe(pipe_class_memory). I assume that will also be how it will work
when your switchable version is in place. That looks reasonable to me
but I wondered if anyone had any thoughts? Ed?

regards,


Andrew Dinn
-----------