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

[Erik Österlund]

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