[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