RFR (S): 8135025: Error message is repeated for large value at G1ConcRefinementThreads

[sangheon.kim]

Hi Jesper,

Thanks for reviewing this again.

Sangheon


On 09/08/2015 01:11 PM, Jesper Wilhelmsson wrote:
> Looks good!
> /Jesper
>
> Den 8/9/15 kl. 21:28, skrev sangheon.kim:
>> Hi all,
>>
>> After some discussion, I decided to propose this webrev.01 version 
>> which has
>> different style from webrev.00.
>>
>> The difference is to add public factory function and privatize the 
>> constructor.
>> So that newly added 'public bool initialize_threads() (from 
>> webrev.00)' is not
>> needed.
>> With this approach we can minimize public function and handle the error
>> situation correctly.
>>
>> Can I get some reviews for this?
>> http://cr.openjdk.java.net/~sangheki/8135025/webrev.01/
>>
>> Thanks,
>> Sangheon
>>
>>
>> On 09/04/2015 10:18 AM, sangheon.kim wrote:
>>> Hi all,
>>>
>>> Can I get some reviews for handling thread creation failure on
>>> ConcurrentG1Refine?
>>>
>>> This pre-existing problem is revealed during commandline test for GC
>>> flags(8078555) which tries to create for 'max_jint-1' threads.
>>> The reason of repeating error message when thread creation failed is 
>>> that we
>>> call 'vm_shutdown_during_initialization' when fails.
>>> And this function just returns and then 'for loop' is continued for 
>>> 'max_jint-1'.
>>>
>>> I separated thread initialization part from the constructor so that 
>>> we can
>>> return when fails to create a new native thread.
>>> And it will be handled from G1CollectedHeap::initialize().
>>>
>>> I didn't add test because it is not stable.
>>> From windows 64, it takes really long time to fail a thread creation 
>>> failure
>>> and hangs the system.
>>> And 8134995(REDO: GC flag validation) will cover this situation.
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8135025
>>> Webrev: cr.openjdk.java.net/~sangheki/8135025/webrev.00
>>> Testing: JPRT
>>>
>>> Thanks,
>>> Sangheon
>>