RFC: One marking bitmap
Roman Kennke
rkennke at redhat.com
Thu Oct 5 15:05:42 UTC 2017
Am 05.10.2017 um 16:57 schrieb Aleksey Shipilev:
> On 10/05/2017 04:53 PM, Roman Kennke wrote:
>> Am 05.10.2017 um 16:51 schrieb Aleksey Shipilev:
>>> On 10/05/2017 12:24 PM, Roman Kennke wrote:
>>>> The main problem has been concurrent class unloading. When we do this, we unload classes that may
>>>> still be referenced by unreachable objects in non-cset regions. When we try to iterate such a region
>>>> object-by-object, we may hit such an object with a dangling Klass* and crash. Always having a valid
>>>> bitmap around means we can iterate based on actual liveness info, which guarantees us to skip dead
>>>> objects with dangling Klass*.
>>> I do not understand this explanation. Actually, I don't understand how second bitmap avoids this
>>> issue. One marking bitmap is *also* valid after class unloading (during final mark) had happened,
>>> and we can iterate over it safely. Can you do the more verbose example?
>> I probably missed the part where we would cancel marking and don't have a valid marking bitmap to
>> support safe iteration that skips unreachable objects...
> But if we *do* cancel the marking, we either follow to degenerate final mark that completes the
> bitmap, or we slide to Full GC. Where's the issue? I need verbose example. And you probably need it
> too! And anyone who would be reading this thread years later -- too!
Ok, you're right. Sorry.
The issue is, or at least was (not sure it is still the case), that we
would not slide into full GC. Instead, we do an update-refs pass to fix
up any references before sliding into full GC. This would crash because
of dangling Klass*.
I have to admit that my memory is a little blurry. I am currently
experimenting with getting rid of the 2nd bitmap. If there are any
unsolvable issues, I'll find out and put it on record once and for all :-)
Roman
More information about the shenandoah-dev
mailing list