RFR: JDK-8078904 : CMS: Assert failed: Ctl pt invariant

[Eric Caspole]

Hi Tom,
I am not sure about the theory of the existing algorithm, it does not 
seem too robust. The 2* still did not leave enough room to hold all the 
possible entries from the per-thread arrays. It was not that hard to 
find a combo of thread count and MinTLABSize that would trigger the 
assert in the original code. However, the only downside of the existing 
code was bad distribution of work in the rescan tasks.
Now it is assured there will be room in the main array with this new change.
Eric


On 8/6/2015 11:40 AM, Tom Benson wrote:
> Hi Eric,
> I understand the comment below resulting in no longer preventing 
> max_plab_samples from getting smaller than 2k.  But I see the factor 
> of 2 in computing _survivor_chunk_capacity and array size was also 
> removed, which would have affected any size.  Was that just viewed as 
> an arbitrary inflation, or ?
> Tnx,
> Tom
>
> On 8/6/2015 9:28 AM, Eric Caspole wrote:
>> Thomas and I had a IM about this the other day and in the end decided 
>> to allow the main rescan chunk array to grow if the user explicitly 
>> sets a very small MinTLABSize on the command line. There doesn't seem 
>> to be any good reason to set a very small MinTLABSize except maybe 
>> stress testing, and so it is simpler to grow this structure for that 
>> unusual case rather than use the stride I had in v03.
>>
>> The new one is here:
>>
>>  http://cr.openjdk.java.net/~ecaspole/JDK-8078904/04/webrev/
>>
>> Bug:
>>  https://bugs.openjdk.java.net/browse/JDK-8078904
>>
>> I tested this with the failing example using many combinations of gc
>> thread counts and many MinTLABSize values from 64 up to 4M. And JPRT.
>> Thanks,
>> Eric
>