RFR (M) 8157726: VarHandles/Unsafe should support sub-word atomic ops

[Aleksey Shipilev]

Mail glitch: this is an old duplicate, please ignore, use the thread
with "[RESEND]" in it. Sorry about this.

-Aleksey

On 05/27/2016 04:34 PM, Aleksey Shipilev wrote:
> (Please note this work is covered with FC exception)
> 
> Hi,
> 
> Please review the VarHandles/Unsafe support for sub-word atomic ops:
>   https://bugs.openjdk.java.net/browse/JDK-8157726
> 
> Webrevs:
>   http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/
>   http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/
> 
> It *looks* like a lot of changes, but the bulk of changes are in tests,
> and the rest of product code is mostly duplicating the existing cases
> for the new code.
> 
> Tour of the changes:
> 
> Unsafe.java:
> 
>   *) Implements the baseline implementation for subword CASes, which
> does the CAS loop within an aligned integer word. While we could
> potentially detect 64-bit platform and do aligned long word instead,
> this complicates implementation for no reason. 32-bit CASes are ubiquitous.
> 
>   *) Provides the entry points for VarHandles implementation. While
> Unsafe provides the implementation for byte/short atomic ops only, it
> also provides the boolean/char versions that are trivially implementable
> with byte/short ops. While we could instead make VarHandles do this
> conversion, it proved harder to do this in VarHandle templates, rather
> than in Unsafe.
> 
>   *) Consistently uses weakCompareAndSetVolatile for CAS loops, in both
> new and old code, which is important for a fallback implementation to
> work well on non-x86 platforms.
> 
> VarHandles*:
> 
>   *) Now mentions subword atomic ops are available in method spec. CCC
> is in progress.
> 
>   *) VarHandle templates are slightly modified to do narrowing
> conversions for shorter-than-int types. This keeps us from putting the
> entire family of addAndGet methods to Unsafe.
> 
>   *) Test templates are changed to accommodate new code shapes, and also
> change the bit patterns we use to detect endianness issues.
> 
> ------ everything above does functionally complete subword ops ------
> ------- everything below is the key performance optimization --------
> 
> Platform-independent changes:
> 
>  *) vmSymbols.hpp, library_call.cpp and other changes: the usual set of
> scaffolding for Unsafe intrinsics. We reuse most of the infrastructure,
> adding new nodes/cases in the existing code.
> 
>  *) Unsafe tests are changed to accommodate new code shapes, and also
> change the bit patterns we use to detect endianness issues.
> 
> x86-specific changes:
> 
>  *) Full set of new x86_{32|64} intrinsics are provided in
> .ad/assembler_x86 files. Supporting 8-byte and 16-byte ops required
> introducing new operations in x86 assembler. These are tested by
> compiler/unsafe tests, which are designed to test int/C1/C2 implementations.
> 
> 
> Performance data justifies the change, and highlights pitfalls:
>   http://cr.openjdk.java.net/~shade/8157726/notes.txt
> 
> 
> Testing: eyeballing assembly; targeted microbenchmarks;
> {java/lang/invoke/VarHandles, compiler/unsafe} tests on x86_{32|64},
> POWER7; RBT hs-comp-tier0.
> 
> Thanks,
> -Aleksey
>