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

[Jesper Wilhelmsson]

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
>