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

[Mikael Gerdin]

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
>