RFR(S): 8075214: SIGSEGV in nmethod sweeping
david.holmes at oracle.com
Thu Mar 26 00:59:38 UTC 2015
As per Mikaels comments there are a lot of issues with this code. The
Java exception handling is one part. Overall it is a hybrid mix of the
other ways we create threads in the VM. See CompileBroker::make_thread
(which you may have used as a partial template) but note the exception
handling and that Thread::start is called while the Threads_lock is held
(which is not the case in the WB code - old or new - which may address
the other issue in JDK-8072377).
Please cc me in any reply as I'm not this list.
> please review the following patch.
> The test uses the Whitebox API to enforce sweeping by creating and starting a 'CodeCacheSweeperThread'. During creation of the thread, the interpreter crashes in j.l.ThreadGroup.add(Thread t)  while executing a subtype check to validate that 't' is a subtype of j.l.Thread . The problem is that we pass 'JavaThread->threadObj()' to 'ThreadGroup.add' which is invalid due to a GC that moved the object. The GC does not know about the thread because it was not yet added to the threads list and therefore does not update the oop.
> Instead of calling 'JavaThread::allocate_threadObj', the initialization is moved to the caller to make sure that setting the thread oop is done together with adding the thread to the threads list. I also fixed the missing oom handling described as one of the problems in JDK-8072377 .
> - 1k runs of failing testcase
> - JPRT
>  http://hg.openjdk.java.net/jdk9/hs-comp/jdk/file/tip/src/java.base/share/classes/java/lang/ThreadGroup.java#l896
>  see '__ gen_subtype_check' in 'TemplateTable::aastore'
>  https://bugs.openjdk.java.net/browse/JDK-8072377
More information about the hotspot-compiler-dev