RFR(M): 8153076: Atomic::* on Solaris should use inline assembly instead of .il files

[Dean Long]

Hi Erik.  Does this work any better?

   __asm__ volatile ("lock; addl $1,%0" : "+m" (*dest) : : "cc", "memory");


dl

On 4/8/2016 4:52 AM, Erik Österlund wrote:
> Hi,
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8153076
> Webrev: http://cr.openjdk.java.net/~eosterlund/8153076/webrev.00/
>
> On Solaris, the Atomic class puts its assembly in a separate .il file, 
> then the code blobs are declared as extern "C" and called from Atomic. 
> More modern GCC-style inline assembly is now supported, and we should 
> use that instead. It works fine the way it is, but making calls just 
> to get an instruction that could be inlined, seems suboptimal.
>
> There are two important things to note:
>
> 1) I have removed all the 32 bit code from solaris Atomic, and weird 
> combinations with GCC and compiler1. JDK9 is only supported on 64 bit 
> SPARC and x86, building using Solaris Studio. Since it is using 
> GCC-style inline assembly, the code should work with GCC too, but I 
> have not tested that as it is not a supported way of building OpenJDK. 
> I personally do not think we should spend too much time on supporting 
> unsupported code.
>
> 2) There appears to be a bug in Solaris Studio for emitting memory 
> accesses on x86.
>
> The following code:
>
> inline void Atomic::inc    (volatile jint*     dest) {
>   __asm__ volatile ("lock; addl $1,(%0)" :
>                     : "r" (dest) : "cc", "memory");
> }
>
> generated the following in HandleMark::initialize(Thread* thread) on 
> Solaris, x64, using SS12.4:
>
> lock addl $1, (%eax)
>
> Note the %eax instead of %rax. It is wrong and caused SIGSEGV as the 
> address was truncated, and libraries are not put within the first 4 GB 
> of VA.
>
> I worked around the issue by assigning the address operands to a fixed 
> register, rdx. Being awkward with the choice of registers is still 
> better than having to make calls. This will have to be fixed, once the 
> solaris studio bug is fixed.
>
> Note that for SPARC there were no issues like this and the generated 
> code is fine.
>
> Testing: JPRT
>
> I need a sponsor to push this.
>
> Thanks,
> /Erik