volatile read and writes

[D.Sturm]

Thanks Thomas, yes I see where that would be changed. One alternative to
introducing additional methods (for read/write) that can be overwritten by
subclasses if they want custom behavior would be to just add a boolean
"isVolatile" field to the WriteNode/ReadNode/FloatingReadNode nodes.
Looking at the layout of those classes the additional boolean field would
be for "free" i.e. just fill up some of the padding, so it wouldn't cost
extra memory for architectures that don't need that information. The
unnecessary memory barriers get just ignored in the LIRGenerator so no
problem there. Would avoid having to subclass the nodes and then handling
the different classes in the LIR generator.

-Daniel


On 1 October 2013 21:51, Thomas Wuerthinger
<thomas.wuerthinger at oracle.com>wrote:

> Daniel,
>
> You can consider customising the code in HotSpotRuntime for Aarch64 that
> creates the memory barrier pattern for volatile loads/stores. Currently we
> create pre- and post-barriers for both volatile loads and stores. We could
> consider making the kind of nodes introduced dependent on the platform.
>
> - thomas
>
> On Sep 29, 2013, at 12:55 AM, D.Sturm <D.Sturm42 at gmail.com> wrote:
>
> > The Aarch64 ISA allows to fold most memory barriers into special load and
> > store instructions - similar to IA64. That means we can get away with
> only
> > explicitly generating StoreLoad barriers and use
> load-acquire/store-release
> > for volatile read/writes and when publishing newly constructed objects
> with
> > final fields.
> >
> > What is the best approach for getting this information when generating
> > load/stores or maybe during a peephole optimization?
> >
> > There's a lastLocationAccess for the FloatingReadNode which should point
> to
> > a MembarNode if it's a volatile read (and there's a next field for
> > storenodes which should do the same), but that seems rather fragile.
> >
> >
> > - Daniel
>
>