RFR: JDK-8078904 : CMS: Assert failed: Ctl pt invariant
eric.caspole at oracle.com
Thu Aug 6 18:20:10 UTC 2015
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.
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 ?
> 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:
>> 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.
More information about the hotspot-gc-dev