volatile read and writes

[Thomas Wuerthinger]

The memory barriers are currently necessary to also ensure the ordering of volatile loads and normal loads [1]. We should still consider changing the system later, but for now it would be best if you can implement your volatile accesses according to the existing architecture so we get a complete picture of requirements.

Thanks, thomas

[1] http://g.oswego.edu/dl/jmm/cookbook.html

On Oct 2, 2013, at 6:58 PM, D.Sturm <D.Sturm42 at gmail.com> wrote:

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