RFC: One marking bitmap

[Roman Kennke]

Funny. Exactly what I was wondering/thinking about last night... Let's discuss later on irc

Am 5. Oktober 2017 11:02:42 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>Hi,
>
>I am trying to understand why do we need two marking bitmaps. "Next"
>bitmap is built during
>concurrent mark, and then gets swapped for the "complete" one at the
>end of concurrent mark. After
>that, all users poll "complete" bitmap for the actual data. But, there
>seem to be no users that need
>to do that when concmark is running, or they can poll "next" bitmap
>too!
>
>There are two problematic points I see:
>a) with single bitmap, concurrent mark cannot be abandoned without
>additional action, because
>marking bitmaps may be incomplete on abort. But in our code, aborted
>concurrent mark leads either to
>degenerate final mark, or to full GC, where we finish building the
>bitmaps again;
>b) with single bitmap, we need to clean the bitmaps *before* the init
>mark, and that means before
>setting TAMS -- which means is_marked() is unreliable in that time
>window. That seems not to be a
>problem, since nothing polls marked data when the concurrent cycle is
>initiated;
>
>This experimental patch cuts out one bitmap, and thus trims down our
>native footprint ~2x:
> http://cr.openjdk.java.net/~shade/shenandoah/wip-one-bitmap/webrev.01/
> (passes hotspot_gc_shenandoah)
>
>Thoughts? What do I miss?
>
>Thanks,
>-Aleksey

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.