Request for review: 8008079 G1: Add nextObject routine to CMBitMapRO and replace nextWord

Srinivas Ramakrishna ysr1729 at gmail.com
Fri Mar 1 23:25:39 PST 2013


Looks good to me too. I'd suggest a one-line doc for the new
getNextObject() method stating that
the argument to the method should be the address of a valid object. I don't
think an assertion is
necessary in the method to check for that because, I am guessing,
obj->size() will already have
some form of sanity check/assertion that would assert if it's not the start
address of a valid object.

-- ramki

On Fri, Mar 1, 2013 at 5:19 PM, Tao Mao <tao.mao at oracle.com> wrote:

>  integrated the suggestion. A new webrev is updated.
> http://cr.openjdk.java.net/~tamao/8008079/webrev.01/
>
> again, passed gc-test-suite for fastdebug build with stressing marking
> cycles
> script:
> ./run.sh /home/tamao/jdk1.8.0 --bits 64 --args -tamao -XX:+UseG1GC
> -XX:InitiatingHeapOccupancyPercent=5 -XX:+UnlockDiagnosticVMOptions
> -XX:+VerifyDuringGC
>
>
> On 2/25/13 3:06 PM, John Cuthbertson wrote:
>
> Hi Tao,
>
> Looks fine except for the following nits....
>
> concurrentMark.hpp:100
> Can you remove the line:
>
> // XXX Fix these so that offsets are size_t's...
>
> concurrentMark.hpp:111
> It might be safer to return:
>
> return offsetToHeapWord(heapWordToOffset(addr + obj->size()));
>
> or assert something like:
>
> HeapWord* res =  addr + obj->size();
> assert(offsetToHeapWord(heapWordToOffset(res)) == res, "sanity");
> return res;
>
> JohnC
>
> On 2/21/2013 6:16 PM, Tao Mao wrote:
>
> 8008079 G1: Add nextObject routine to CMBitMapRO and replace nextWord
> https://jbs.oracle.com/bugs/browse/JDK-8008079
>
> webrev:
> http://cr.openjdk.java.net/~tamao/8008079/webrev.00/
>
> changeset:
> When concurrent marking scans an object, the task local finger is updated
> to point to the start of the object. If the marking task is asked to abort,
> the local finger is updated to the next word where another could possibly
> start. When the marking task is restarted, we restart scanning the marking
> bitmap from the updated local finger.
>
> This is a safe implementation but has not been fully exploited for
> efficiency because the contents of the marking bitmap should be all 0's
> until the offset associated with the actual start of the next object. When
> the marking task is restarted, we will scan these 0's looking for the first
> set bit.
>
> We can avoid this redundant scanning by updating the finger to and
> re-starting the scan at the actual offset where the next object starts.
>
> testing:
> passed gc-test-suite with stressing marking cycles
> script:
> ./run.sh /home/tamao/jdk1.8.0 --bits 64 --args -tamao -XX:+UseG1GC
> -XX:InitiatingHeapOccupancyPercent=10 -XX:+UnlockDiagnosticVMOptions
> -XX:+VerifyDuringGC
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20130301/b0b42639/attachment-0001.html 


More information about the hotspot-gc-dev mailing list