volatile read and writes

[D.Sturm]

Not sure I can follow you: Do you want me to not change the
HotSpotRuntime class
at all and just explicitly generate all those memory barriers for now?

To clarify: ldar is "load; LoadLoad, LoadStore" while stlr is "LoadStore,
StoreStore; store" so those cover everything but the post-volatile-write
barriers from the cookbook and what graal does. The post-volatile-write
StoreLoad barrier has to be explicitly generated in all cases.

-Daniel

On 2 October 2013 22:31, Thomas Wuerthinger
<thomas.wuerthinger at oracle.com>wrote:

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