Alex Blewitt wrote: > However, if the GC is generational, why does it need to be contiguous?
As far as I know, there are no theoretical obstacles in making GC heap non-contiguous. The heap is created in contiguous address range mostly because of practical reasons. 1) it is very convenient to be able to do assert(object >= heap_base && object < heap_ceiling) 2) a well-known design for heap traversal during garbage collection involves having so called mark bit table, which has 1 bit for each potential object start location. For example, in current DRLVM GC (called "GC v4"), objects are 4 bytes aligned, thus each 4-byte aligned address can potentially be a start of an object, and so has a corresponding mark bit in the table. To extend the mark bits techniques on non-contiguous heaps, one have to split the heap space into 2^n byte blocks and allocate mark bit tables for each block. GC v4 uses this techniques, with block size = 128k, and first 4k of the block keeping the mark bit table. However, in case of GC v4, it has a design flaw. It tries to organize the LOS (Large object space) uniformly with small object blocks, and has large objects aligned at the block level. The objects larger than 1/2 of the block are considered large. In the worst case, if the heap is filled with the objects of size about 1/2 of block, more than 50% of the heap space is wasted for alignment. I think that the space inefficiency can be fixed by introducing separate logic for handling large objects, and aligning them to a smaller boundary, e.g. on a page size (4k). --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
