RFR(S): 8134889: Kitchensink stress test crashes with out of memory error

[Derek White]

Thanks Mikael!

On 5/3/16 4:00 AM, Mikael Gerdin wrote:
> Hi Derek,
>
> On 2016-05-02 18:06, Derek White wrote:
>> Hi Mikael,
>>
>> I promised a webrev, but got buried by gatekeeping for a few days.
>>
>> WEBREV: http://cr.openjdk.java.net/~drwhite/8134889/webrev.02/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~drwhite/8134889/webrev01.v.02/
>
> Looks good!
>
> /Mikael
>
>
>>
>> Thanks!
>>
>>   - Derek
>>
>> On 4/26/16 6:37 PM, Derek White wrote:
>>> Hi Mikael,
>>>
>>> On 4/21/16 10:36 AM, Derek White wrote:
>>>> Hi Mikael,
>>>>
>>>> On 4/21/16 4:02 AM, Mikael Gerdin wrote:
>>>>> Hi Derek,
>>>>>
>>>>> On 2016-04-20 23:48, Derek White wrote:
>>>>>> Still looking for reviews for a small fix for a P2 bug...
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> On 4/7/16 6:07 PM, Derek White wrote:
>>>>>>> Summary:
>>>>>>> The remaining part of this bug deals with running out of address
>>>>>>> space
>>>>>>> on 32-bit JVMs running on Win64. This fix is simply to have a hard
>>>>>>> limit on GC threads (still larger than necessary) on 32-bit 
>>>>>>> JVMs. The
>>>>>>> new limit is 16 (2 * switch_pt).
>>>>>>>
>>>>>>> Note that this overlaps somewhat with several "# of GC thread" bugs
>>>>>>> including:
>>>>>>>  - 8131932 <https://bugs.openjdk.java.net/browse/JDK-8131932> :
>>>>>>> Ergonomics oversize number of GC threads for small JVMs on large
>>>>>>> systems
>>>>>>>  - 8153225 <https://bugs.openjdk.java.net/browse/JDK-8153225>: G1
>>>>>>> creates too many concurrent refinement threads by default
>>>>>>>  - 7189147 <https://bugs.openjdk.java.net/browse/JDK-7189147>: GC
>>>>>>> threads should be created as needed not all at once
>>>>>>>
>>>>>>> Doing the correct thing in general will require a lot more
>>>>>>> performance
>>>>>>> analysis. The fix here is simple, only affects 32-bit JVMs 
>>>>>>> running on
>>>>>>> >= 24 core machines, and will reduce OOM crashes in nightly 
>>>>>>> testing.
>>>>>>>
>>>>>>> BUG: 8134889 <https://bugs.openjdk.java.net/browse/JDK-8134889>
>>>>>>> WEBREV: http://cr.openjdk.java.net/~drwhite/8134889/webrev.01/
>>>>>
>>>>> Fix looks good.
>>>>> I wonder about the cast to unsigned int, though.
>>>>> It seems weird that it's needed since all the other operands are
>>>>> unsigned ints in the calculation.
>>>>
>>>> Yes, that does look weird. I can't recall why I added it either.
>>>>
>>>>      unsigned int switch_pt = bar;
>>>>      unsigned int threads = foo;
>>>>      threads = MIN2(threads, 2*switch_pt)
>>>>
>>>> Wait a minute, according to the interweb, the type of the literal '2'
>>>> is "int" (eg. signed). I think one compiler complained on a jprt run.
>>>> Doing a jprt run without the cast...
>>> So jprt is happy with or with the cast. I had the type promotion rules
>>> wrong in my head.
>>> signed * unsigned = unsigned.
>>>
>>> I'll remove the cast and update the webrev.
>>>
>>> Thanks,
>>>
>>>   - Derek
>>