RFR (S) 8209889: RedefineStress tests crash
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Thu Oct 4 18:28:28 UTC 2018
On 10/4/18 2:00 PM, dean.long at oracle.com wrote:
> So having a raw CompileTask* is like having a raw Method*. I'm
> tempted to suggest a new CompiledTaskHandle, but it would only be used
> in one place, so how about changing CompileTaskWrapper so we could do
> something like this instead:
>
> CompileTaskWrapper ctw(queue->get());
> CompileTask* task = ctw.task();
I started down this path but since CompileTaskWrapper cannot completely
encapsulate CompileTask to make it safe, the code I have I think is just
as good. Also, adding NULL checks seems like it would allow some new
behavoir that is now an invariant (ie CompileTask is never NULL).
Thanks,
Coleen
>
> CompileTaskWrapper would need to be able to handle a NULL task
> gracefully.
>
> dl
>
> On 10/4/18 4:45 AM, coleen.phillimore at oracle.com wrote:
>> Summary: Create CompileTaskWrapper before potential safepoint
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8209889.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8209889
>>
>> MetadataOnStackMark needs to find the CompileTask in the current
>> thread, or else the Method isn't marked as being alive, so if it's
>> old/obsolete, it is freed. There are checks to disable adding old
>> methods to the compile queue but if the method is redefined after
>> this point, there may be a preexisting bug that we compile an old
>> method. This change just fixes the crash.
>>
>> Can some compiler person (Martin?) look at where I moved
>> possibly_add_compiler_threads and let me know if that looks okay?
>> There's a comment in the change that says why you need to create the
>> CompileTaskWrapper before that call. I couldn't find a place to put
>> a NoSafepointVerifier.
>>
>> Tested with the test that failed, which doesn't reproduce the bug
>> except rarely, and test/hotspot/jtreg/compiler tests. tier1 an 2 in
>> progress.
>>
>> Thanks,
>> Coleen
>
More information about the hotspot-dev
mailing list