Request for review (S): 7029036: Card-table verification hangs with all framework collectors, except G1, even before the first GC
Y. Srinivas Ramakrishna
y.s.ramakrishna at oracle.com
Thu Mar 24 17:08:02 UTC 2011
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!
> 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
>> 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
More information about the hotspot-gc-dev