RFR 8249217: Unexpected StackOverflowError in "process reaper" thread still happens
Roger Riggs
Roger.Riggs at oracle.com
Wed Jul 22 19:36:51 UTC 2020
Hi Peter,
yes, the reference to ConcurrentHashMap seems ineffective and unnecessary.
Updated Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-1/
Thanks, Roger
On 7/22/20 10:58 AM, Peter Levart wrote:
> Hi Roger,
>
>
> I don't think resolving the ConcurrentHashMap.class ensures
> initialization of the class. Just loading. But I think CHM is already
> initialized at that time as it is used in ClassLoader to maintain
> class loading locks (per class name).
>
>
> Regards, Peter
>
>
> On 7/22/20 4:51 PM, Roger Riggs wrote:
>> Please review a change to the Process reaper thread initialization to
>> preemptively
>> make sure classes ThreadLocalRandom and ConcurrentHashMap are
>> initialized.
>> From the stack overflow failures, it seems that the classes have not
>> been initialized
>> before they are used during processing the termination of a process.
>> When the initialization is performed on the smaller reaper stack, it
>> occasionally
>> exceeds the available stack.
>>
>> As an aid to diagnostics,
>> -XX:AbortVMOnException=java.lang.StackOverflowError
>> is added to TestHumongousNonArrayAllocation that has failed
>> intermittently.
>> If the problem happens again it will produce an hs_error file with
>> useful details
>> and will otherwise not change the test behavior.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8249217
>>
>> Thanks, Roger
>>
More information about the core-libs-dev
mailing list