Ping: RFR: JDK-8205523: Explicit barriers for interpreter

[Roman Kennke]

Am 27. Juni 2018 12:31:26 MESZ schrieb Andrew Haley <aph at redhat.com>:
>On 06/27/2018 11:02 AM, Erik Österlund wrote:
>
>> I think that for the non-GC developers, it gets more tricky if they
>> have to remember not to perform any writes because somewhere further
>> up in the call hierarchy, the oop was only resolved for reading. Or
>> that any reads used have to be non-volatile, or you risk running
>> into a subtle IRIW situation (even on TSO hardware) due to having
>> multiple reads riding on the same read resolve, potentially causing
>> inconsistencies. It won't be a problem in the places you inserted
>> the read resolves to now.
>
>It would be correct to resolve everything for writes, but would not
>help performance, and we're trying to improve performance, not make it
>worse.
>
>With respect to volatility, read and write barriers mean that
>developers have to pay attention to volatility.  But that's already
>true even for TSO: for example, you can't hoist the result of a
>volatile read into a register and use it again.  Given that non-GC
>developers have to be aware of volatility anyway, what would be hurt
>by having to mark volatile reads?  I would argue that it would make
>code more explicit and thus more maintainable, and we have to do it in
>all of the C++ code anyway.  Sure, this is a new discipline for x86
>HotSpot developers.

It should be noted that normal loads and stores are already covered by the Access API, and we emit the correct read- and write barriers. This is about a few places that don't easily fit that model and still require barriers. That is monitor enter/exit (need WBs anyway) and a few intrinsics, in the interpreter only CRC32. This requires an RB on the buffer array. Yeah, it's probably OK to emit WB there too. If it's really hot, it'd be compiled by C1 or C2.

Roman

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.