[9] RFR(S): 8075214: SIGSEGV in nmethod sweeping
Tobias Hartmann
tobias.hartmann at oracle.com
Tue Mar 31 05:17:08 UTC 2015
Thanks, Vladimir.
Best,
Tobias
On 30.03.2015 18:12, Vladimir Kozlov wrote:
> Thank you for testing, Tobias.
>
> Changes are good.
>
> Thanks,
> Vladimir
>
> On 3/27/15 2:27 AM, Tobias Hartmann wrote:
>> Thanks, Vladimir.
>>
>> On 26.03.2015 17:06, Vladimir Kozlov wrote:
>>> Please, also verify that original failing tests from 8064669 are also passing.
>>
>> The original failing tests were
>>
>> compiler/whitebox/AllocationCodeBlobTest.java
>> compiler/codecache/OverflowCodeCacheTest.java
>>
>> Both pass 1k runs on my machine and JPRT runs with different flags.
>>
>> We should also close 8072377 after this is pushed.
>>
>> Best,
>> Tobias
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8072377
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 3/26/15 5:52 AM, Tobias Hartmann wrote:
>>>> Hi Vladimir,
>>>>
>>>> On 25.03.2015 18:10, Vladimir Kozlov wrote:
>>>>> This is messy. Tobias, can you investigate if we can have the same functionality (sweeping on request) in already running sweeper thread without crating new thread for that? It may require additional synchronization which should be fine since it is testing - no need to worry about performance.
>>>>
>>>> I agree. I removed creation of a new sweeper thread and added the method NMethodSweeper::force_sweep() to enforce a sweep by setting '_force_sweep', notifying the sweeper and waiting for completion. Synchronization is done by using the CodeCache_lock.
>>>>
>>>> Here are the new webrevs:
>>>> http://cr.openjdk.java.net/~thartmann/8075214/top/webrev.00/
>>>> http://cr.openjdk.java.net/~thartmann/8075214/webrev.01/
>>>>
>>>> I executed 1k runs of the failing test.
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>> I looked in reviews of original changes for 8064669 and we did not ask about that.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 3/25/15 6:53 AM, Tobias Hartmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> please review the following patch.
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075214
>>>>>> http://cr.openjdk.java.net/~thartmann/8075214/webrev.00/
>>>>>>
>>>>>> Problem:
>>>>>> 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) [1] while executing a subtype check to validate that 't' is a subtype of j.l.Thread [2]. 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.
>>>>>>
>>>>>> Solution:
>>>>>> 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 [3].
>>>>>>
>>>>>> Testing:
>>>>>> - 1k runs of failing testcase
>>>>>> - JPRT
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/jdk/file/tip/src/java.base/share/classes/java/lang/ThreadGroup.java#l896
>>>>>> [2] see '__ gen_subtype_check' in 'TemplateTable::aastore'
>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8072377
>>>>>>
More information about the hotspot-compiler-dev
mailing list