JDK-8057822 : assert(allow_zombie || !is_zombie()) failed: should not call follow on zombie nmethod
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2014-09-08
  • Updated: 2016-03-16
  • Resolved: 2016-03-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Duplicate :  
JDK-8059735 - make_not_entrant_or_zombie sees zombies
Duplicate :  
JDK-8075805 - Crash while trying to release CompiledICHolder
Relates :  
JDK-8152010 - [JVMCI] assert(allow_zombie || !is_zombie()) failed: should not call follow on zombie nmethod
Description
Assertion failed on  24 cores, 144G, Win32 / Windows Server 2008 R2 Enterprise

#  Internal Error (C:\jprt\T\P1\153504.amurillo\s\hotspot\src\share\vm\code\nmethod.cpp:2097), pid=36344, tid=35928
#  assert(allow_zombie || !is_zombie()) failed: should not call follow on zombie nmethod
Comments
Confusing :-)
16-03-2016
[~twisti], the call to G1SATBCardTableModRefBS::write_ref_nmethod_pre() in nmethod::clear_jvmci_installed_code() was not added with JDK-8143571 but just changed. I filed JDK-8152010 for the JVMCI failures but then noticed that the last failure was before JDK-8143571 was fixed. Closed it as duplicate (please re-open if it turns out not to be fixed).
16-03-2016
I had a look at the original failure from 2014 and I'm pretty confident that the underlying problem is fixed now. I think it's very similar to what happened with JDK-8059735: While processing an alive nmethod nm in the sweeper, we hit a safepoint (for example, in possibly_flush) and convert nm to zombie in CodeCache::make_marked_nmethods_zombies(). We continue execution in the sweeper and hit another safepoint (for example, now in MutexLocker cl before cleaning up inline caches). During the second safepoint, the GC visits all JavaThreads and invokes CodeCacheSweeperThread::oops_do() which calls do_code_blob(_scanned_nmethod) to prevent the current nmethod from being unloaded. Since _scanned_nmethod == nm we hit the assert in nmethod::oops_do() because the nmethod is zombie now. CodeCache::make_marked_nmethods_zombies() was completely removed with JDK-8075805, so this should be fixed. For the record, I'll close this as duplicate. Please file a new bug for the JVMCI/AOT failures. Most likely the fix for JDK-8143571 introduced a new issue
16-03-2016
[~never] added the G1SATBCardTableModRefBS::write_ref_nmethod_pre call with JDK-8143571.
10-03-2016
Here is the stack trace for the Graal failure: Stack: [0x00007f70b93e2000,0x00007f70b94e3000], sp=0x00007f70b94e1510, free space=1021k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x13cd3f5] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x155 V [libjvm.so+0x13ce0df] VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f V [libjvm.so+0x94022f] report_vm_error(char const*, int, char const*, char const*, ...)+0xcf V [libjvm.so+0x106be3c] nmethod::oops_do(OopClosure*, bool)+0x33c V [libjvm.so+0xb048f0] G1SATBCardTableModRefBS::write_ref_nmethod_pre(oop*, nmethod*)+0x260 V [libjvm.so+0x1072d5b] nmethod::clear_jvmci_installed_code()+0xbb V [libjvm.so+0x1072fe5] nmethod::maybe_invalidate_installed_code()+0x265 V [libjvm.so+0x1074e84] nmethod::make_not_entrant_or_zombie(unsigned int)+0x2e4 V [libjvm.so+0x12dc2d7] NMethodSweeper::process_nmethod(CompiledMethod*)+0x367 V [libjvm.so+0x12dd273] NMethodSweeper::sweep_code_cache()+0x1f3 V [libjvm.so+0x12ddc6f] NMethodSweeper::possibly_sweep()+0x1ef V [libjvm.so+0x12de1bd] NMethodSweeper::sweeper_loop()+0x33d V [libjvm.so+0x133b2e6] JavaThread::thread_main_inner()+0x1d6 V [libjvm.so+0x133b53c] JavaThread::run()+0x1cc V [libjvm.so+0x10be8e2] java_start(Thread*)+0xd2 C [libpthread.so.0+0x7851]
10-03-2016
This assert triggered two times: 2014-09-05 and 2015-12-04. The latter one was with Graal as compiler.
10-03-2016
This looks like a compiler issues. I'm moving this to the compiler team for further assessment.
10-03-2016
ILW: I: high -> assertion failure L: low -> only one machine W: high -> none -> P2
09-09-2014
http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=579944.VMSQE.PIT-89&show-limit=0&filter= RULE vm/gc/concurrent/lp50yp10rp30mr70st300t1 Crash Internal Error ...nmethod.cpp...assert(allow_zombie || !is_zombie()) failed: should not call follow on zombie nmethod could be related to: JDK-8057820
08-09-2014