RFR 8230765: Implement nmethod barrier for x86_32 platforms
zgu at redhat.com
Tue Nov 26 18:07:07 UTC 2019
On 11/26/19 8:24 AM, Zhengyu Gu wrote:
>> 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.
I took your patch. There is just one little hiccup: compiler expects
intptr_t instead of int* on x86_32, the fix is straightforward.
- __ movptr(tmp, bs_nm->disarmed_value_address());
+ __ movptr(tmp, (intptr_t)bs_nm->disarmed_value_address());
Address disarmed_addr(tmp, 0);
__ cmpl(disarmed_addr, 0);
Full webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.02/
and patch passed submit tests.
Okay to push?
>> 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