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