[8u] RFR: JDK-8164041: support old pre-c++11 toolchains and ucLibc

[Edward Nevill]

Hi Andrey,

I tried applying your patch and got the following errors

Compiling
/work/ed/aarch32/jdk8u/hotspot/src/share/vm/runtime/atomic.cpp
{standard input}: Assembler messages:
{standard input}:254: Error: selected processor does not support ARM
mode `ldrexd r4,r5,[r2]'
{standard input}:269: Error: selected processor does not support ARM
mode `ldrexd r4,r5,[r2]'
{standard input}:288: Error: selected processor does not support ARM
mode `ldrexd r8,r9,[r2]'
{standard input}:291: Error: selected processor does not support ARM
mode `strexdeq r3,r6,r7,[r2]'

This was running on a trusty chroot using gcc 4.9.1 on a Samsung
Chromebook (ARM v7).

In general I would prefer to use the builtin atomics where possible.

However I do have some sympathy with the logic that says lets just do
it in assembler because we know it is right then and we can't trust
gcc.

This comes from debugging the atomic primitives on aarch64 and
discovering they were broken in certain versions of gcc. And the
problem is, if they are broken on one version of gcc they might as well
be broken in all versions because, for sure, someone, someday, will use
the broken version and we will end up debugging it.

So I am not religious about using builtins or not. Other people on the
list may have stronger opinions.

However, it must build on my system. I will continue looking at why it
isn't building.

All the best,
Ed.



On Mon, 2016-08-15 at 19:06 +0300, Andrey Petushkov wrote:
> Hi All,
> 
> We met a necessity to support an older kind of gcc toolchain which
> does not fully conform to c++ 11 and in particular do not have
> __atomic API as well as have some other peculiarities. In addition
> the support of ucLibc was desired.
> 
> The resulting changes are here: http://cr.openjdk.java.net/~apetushko
> v/8164041/webrev/
> <http://cr.openjdk.java.net/~apetushkov/8164041/webrev/>
> Checked with running on OpenWRT-based distribution
> 
> When implementing the replacement code we also chosen to always use
> the assembly implementation and not builtins because:
> - there is no harm, the assembly is no worse than that gcc can
> generate
> - the code is more clear
> - there is no reliable way to determine if gcc has flaws or not, so
> the detection directives look really ugly
> 
> Thanks,
> Andrey