RFR (S) 8218851: JVM crash in custom classloader stress test, JDK 12 & 13
David Holmes
david.holmes at oracle.com
Fri Feb 15 13:26:05 UTC 2019
On 15/02/2019 10:04 pm, coleen.phillimore at oracle.com wrote:
> On 2/14/19 8:54 PM, David Holmes wrote:
>> Hi Coleen,
>>
>> On 15/02/2019 2:58 am, coleen.phillimore at oracle.com wrote:
>>> Summary: Handle NULL and unloaded constraint class in loader
>>> constraint table, also cope with unloaded but not cleaned out klass
>>> in loader constraint entries.
>>
>> Pardon my ignorance but how can an unloaded class still be involved in
>> a loader constraint?
>
> The class can be not loaded yet, because we apparently add the klass to
> the loader constraint table before the is_loaded flag is set. It can be
> already unloaded with concurrent class unloading because the table
> hasn't been cleaned out yet. I put interesting bits of the stack trace
> in the bug report.
That sounds really racy. So if we do the check before is_loaded is set
it passes or fails? And if we do the check a millisecond later when
is_loaded is set, it passes or fails? Surely there has to be some
atomicity here.
David
> thanks,
> Coleen
>
>>
>> Thanks,
>> David
>>
>>> Tested overnight with the application that caused the crash. Tested
>>> with hs tier1-6. Tested JCKs with ZGC.
>>>
>>> open webrev at
>>> http://cr.openjdk.java.net/~coleenp/2019/8218851.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8218851
>>>
>>> Thanks,
>>> Coleen
>
More information about the hotspot-runtime-dev
mailing list