[9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies
Albert Noll
albert.noll at oracle.com
Tue Oct 7 11:16:05 UTC 2014
Hi Tobias,
would it also work to check the state of the nmethod before calling
make_zombie?
if (nm->is_not_entrant()) {
nm->make_zombie()
}
In any case, it would be nice the have a comment that explains why we
should not enter a
safpoint / have to do the extra check as described above.
Best,
Albert
On 10/07/2014 01:03 PM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8059735
> Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/
>
> Problem:
> In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is
> processed and can be converted to zombie (line 549 of sweeper.cpp). To
> clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock
> and check for a safepoint. In this case, there is a safepoint request
> and we block. During the safepoint a VM_Deoptimize operation is
> executed (due to classloading) and the non-entrant nmethod is set to
> zombie by 'CodeCache::make_marked_nmethods_zombies'. After the
> safepoint the sweeper continues and tries to set the nmethod to zombie
> again.
>
> Solution:
> Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire the
> CompiledIC_lock.
>
> Testing:
> - Failing tests
> - JPRT
>
> Thanks,
> Tobias
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8058737
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141007/6f8b4728/attachment.html>
More information about the hotspot-compiler-dev
mailing list