Request for review (S): 7029036: Card-table verification hangs with all framework collectors, except G1, even before the first GC

[Y. Srinivas Ramakrishna]

On 3/24/2011 9:01 AM, Jesper Wilhelmsson wrote:
> Is there any particular reason to why you changed it from a while to a for?

more compact :-)

> Either way it looks good. (But it would have looked even better in reviewboard ;))

Yes, we need to get reviewboard talking with openjdk (although
i must still say that i find webrev easier to navigate than
what reviewboard gives me (especially when i am on my laptop
with a relatively small display; from my desktop in the office
with its larger display, it would probably look nice, i should try it).

I'll definitely start using reviewboard soon; thanks for the hint! :-)

> Ship it!

Thanks for the review!
-- ramki

> /Jesper
>
> On 2011-03-24 09:15, Y. Srinivas Ramakrishna wrote:
>>
>> I'd like a few reviews for a fix to the following CR:-
>>
>> 7029036: Card-table verification hangs with all framework collectors, except
>> G1, even before the first GC
>>
>> Problem: This is a day one performance bug in card-table verification
>> infrastructure
>> in the so-called "gc framework", and affects CMS, ParNew and SerialGC.
>> Details on why the problem was unmasked only recently can be found in
>> the bug report. In a nutshell, existing code has quadratic complexity
>> when scanning large arrays because for an object of size O(n)
>> and with k clean card ranges, the cost is O(k.n), which with O(n)
>> worst case clean card ranges would yield O(n^2) cost.
>>
>> Solution: By using a memory-interval-bounded iteration over the
>> clean card ranges of these objects, the complexity is returned
>> to O(k) which is O(n), because we do not end up scanning an
>> entire prefix of the object each time before scanning each
>> clean range.
>>
>> I also simplified the verification closure (for the product build)
>> by ensuring that the iterator never returns reference locations
>> outside the range of clean cards to the closure, which itself just
>> asserts in non-product builds that this is always the case.
>> (This assertion allowed us to find a few memory-interval-delimited
>> iteration methods which were not respecting the memory-interval provided.
>> That is being separately fixed in CR 7034035; stay tuned.)
>>
>> Testing: The tests listed in the bug report with +VerifyBefore/AfterGC
>> to verify that the heap verification now does not "hang" but rather
>> completes very quickly even with much larger heaps. Also refworkload
>> on solaris/x86 and JPRT testing (ongoing) with
>> heap verification switched on.
>>
>> webrev: http://cr.openjdk.java.net/~ysr/7029036/webrev.00/
>>
>> Thanks for your reviews!
>> -- ramki