RFR 8230765: Implement nmethod barrier for x86_32 platforms
zgu at redhat.com
Tue Nov 26 13:24:08 UTC 2019
Thanks for the reviewing and suggestion.
On 11/26/19 5:32 AM, erik.osterlund at oracle.com wrote:
> 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:
Yes, this indeed a much cleaner approach. I will take your proposed
cleanup and run through submit.
> On 11/25/19 9:35 PM, Zhengyu Gu wrote:
>> Hi all,
>> Please review this implementation of nmethod barrier for x86_32
>> 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/
>> hotspot_gc with x86_64 and x86_32 JVM on Linux
>> Submit test.
More information about the hotspot-gc-dev