What are the advantages and disadvantages of having mark bits together and separate for Garbage Collection

Question

I was watching video Google IO 2008 - Dalvik Virtual Machine Internals to understand how Dalvik VM works and why those people has preferred Dalvik VM over JVM for android. I found that android uses separate memory for Garbage information about the objects , opposed to the JVM where we have mark bits(bits telling whether object is able for garbagfe collection or not) together with objects.

Can anybody tell me in detail what are the advantages and disadvantages of having separate memory for marks bits and not having separate memory for mark bits ?

I was unable to get this difference by watching video.

Answer 1

Some advantages of a separate bitmap:

• Much denser. A typical GC needs maybe eight bits of GC metadata, but due to alignment an in-object header might round this memory up to 32 bits.
• Some operations, in particular around sweeping, become faster. This is partly because the denser (see above) bitmap means less memory traffic and better cache use, but also because some operations (e.g. zeroing all mark bits) can be vectorized when in this format. (Other parts of the GC needs to be designed to make use of that ability.)
• If you fork() on a Unix system, a separate bitmark makes better use of copy-on-write: Pages containing objects might remain shared.

Some advantages of in-object mark bits:

• Depending on the scheme used to associate objects with bitmaps, getting the mark bit for an object and vice versa can be quite complicated and/or slow. An in-object header, on the other hand, is trivial to access.
• Easier memory management: No need to create a separate allocation of the right size and keep it in sync.
• Many fast schemes for finding bitmaps for objects and vice versa are quite restrictive in other regards. For example, if you create a bitmap for every page and store the bitmap pointer at the start of the page, you have a problem storing objects larger than a page.