[14] RFR 8230765: Implement nmethod barrier for x86_32 platforms

[erik.osterlund at oracle.com]

Hi Zhengyu,

Nice to see nmethod entry barriers added one more platform configuration.
So now you use a global instead of thread-local on 32 bit x64 as it 
doesn't have a Thread register.
That makes sense. I wonder though if that difference has spread too far 
into the runtime code. It does
sting a bit in my eyes to read the seemingly unnecessary #ifdef _LP64 
macros in BarrierSetNMethod.

In particular, when computing the BarrierSetNMethod::disarmed_value(), 
it seems like it would work
for everyone to simply read the global value, instead of doing it only 
sometimes, and sometimes read
the thread-local.

Here is a patch with my proposed cleanup:
http://cr.openjdk.java.net/~eosterlund/8230765/webrev.02/

Incremental:
http://cr.openjdk.java.net/~eosterlund/8230765/webrev.01_02/

Thanks,
/Erik

On 11/25/19 9:35 PM, Zhengyu Gu wrote:
> Hi all,
>
> Please review this implementation of nmethod barrier for x86_32 
> platforms.
>
> x86_32 implementation mirrors x86_64's. The only difference is where 
> it reads nmethod disarmed value.
>
> Unlike 64-bits, 32-bits platform does not have a dedicated register 
> for current thread. So that it is cheaper to read disarmed value from 
> global location than from per-thread GC data.
>
> Currently, only Shenandoah GC uses the implementation for its 
> concurrent class unloading. This implementation, along with Shenandoah 
> concurrent class unloading, has been baked in shenandoah/jdk repo for 
> some time now,  they are ready for integration.
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8230765
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.01/
>
>
> Test:
>   hotspot_gc with x86_64 and x86_32 JVM on Linux
>   Submit test.
>
> Thanks,
>
> -Zhengyu
>