RFR(XXS): 8214001: DependencyContext::remove_dependent_nmethod() deletion in place is unnecessary

Zhengyu Gu zgu at redhat.com
Fri Nov 16 22:25:27 UTC 2018

Hi Coleen,

On 11/16/18 4:46 PM, coleen.phillimore at oracle.com wrote:
> Hi Zhengyu, your change conflicts with one that ErikO has out for review:
> RFR: 8213565: Crash in DependencyContext::remove_dependent_nmethod

Thanks for pointing out. We did see some weird behavior here (attached 
below), ErikO's patch probably has something to do with it.

I would like to retract my RFR.



# A fatal error has been detected by the Java Runtime Environment:
#  Internal Error 
pid=134111, tid=134153
#  assert(!find_stale_entries()) failed: inconsistent info
# JRE version: OpenJDK Runtime Environment (12.0) (fastdebug build 
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 
12-internal+0-adhoc.jenkins.shenandoah-jdk, mixed mode, sharing, tiered, 
compressed oops, shenandoah gc, linux-amd64)
# No core dump will be written. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp

---------------  S U M M A R Y ------------

Command Line: -Xmx1g -Xms1g -XX:+UnlockExperimentalVMOptions 
-XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions 
-XX:ShenandoahGCHeuristics=aggressive -XX:+VerifyObjectEquals 
-XX:+ShenandoahStoreCheck -XX:+ShenandoahVerifyOptoBarriers 
org.openjdk.jmh.runner.ForkedMain 32974

Host: polwarth.rhts.eng.bos.redhat.com, Intel(R) Xeon(R) CPU E5-2680 v4 
@ 2.40GHz, 56 cores, 251G, Red Hat Enterprise Linux Server release 7.4 
Time: Thu Nov 15 11:24:33 2018 EST elapsed time: 196 seconds (0d 0h 3m 16s)

---------------  T H R E A D  ---------------

Current thread (0x00007fdd5c03d000):  GCTaskThread "Shenandoah GC 
Threads#29" [stack: 0x00007fdd594d6000,0x00007fdd595d6000] [id=134153]

Stack: [0x00007fdd594d6000,0x00007fdd595d6000],  sp=0x00007fdd595d49d0, 
free space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, 
j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x19b223d]  VMError::report_and_die(int, char const*, char 
const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char 
const*, int, unsigned long)+0x15d
V  [libjvm.so+0x19b3107]  VMError::report_and_die(Thread*, void*, char 
const*, int, char const*, char const*, __va_list_tag*)+0x47
V  [libjvm.so+0xb2f289]  report_vm_error(char const*, int, char const*, 
char const*, ...)+0x109
V  [libjvm.so+0xb7889b]  DependencyContext::expunge_stale_entries()+0x9b
V  [libjvm.so+0xe52eab] 
V  [libjvm.so+0x152d847]  KlassCleaningTask::work()+0x137
V  [libjvm.so+0x152dc08]  ParallelCleaningTask::work(unsigned int)+0xf8
V  [libjvm.so+0x1a33736]  GangWorker::run_task(WorkData)+0x66
V  [libjvm.so+0x1a33848]  GangWorker::loop()+0x48
V  [libjvm.so+0x18ee032]  Thread::call_run()+0x72
V  [libjvm.so+0x14e5ff0]  thread_native_entry(Thread*)+0x110

> http://cr.openjdk.java.net/~eosterlund/8213565/webrev.00/src/hotspot/share/code/dependencyContext.cpp.udiff.html 
> All he needs is someone who understands this code to review it!
> Thanks,
> Coleen
> On 11/16/18 4:38 PM, Zhengyu Gu wrote:
>> Hi,
>> Please review this small cleanup.
>> It is not necessary to delete stale entry in place, since it calls 
>> expunge_stale_entries() to purge all stale entries at the end anyway.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214001
>> Webrev: http://cr.openjdk.java.net/~zgu/8214001/webrev.00/
>> Test:
>>  hotspot_compiler on Linux x64 (fastdebug and release)
>> Thanks,
>> -Zhengyu

More information about the hotspot-dev mailing list