Avoiding Full GCs in HBase with MemStore-Local Allocation Buffers: Part 3(cloudera.com)
cloudera.com
Avoiding Full GCs in HBase with MemStore-Local Allocation Buffers: Part 3
http://www.cloudera.com/blog/2011/03/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-3/
4 comments
Azul's concurrent GC is much more clever. They use some tricks with memory mapping in order to perform really efficient read barriers (which traditional VMs have considered too costly). This allows compaction to happen while mutator threads proceed.
This is a nice presentation about it: http://www.research.ibm.com/mre05/Click.pdf
And of course the paper: http://usenix.org/events/vee05/full_papers/p46-click.pdf
This is a nice presentation about it: http://www.research.ibm.com/mre05/Click.pdf
And of course the paper: http://usenix.org/events/vee05/full_papers/p46-click.pdf
That is an awesome GC and I wish I could have it. AFAIK they are having trouble because they mmap/munmap a lot, and virtual memory systems on modern OS don't do that efficiently enough.
Yes, they currently depend on kernel patches to provide bulk map/unmap APIs as well as some other vm_area trickery to allow parts of physical memory to be mapped to multiple places in virtual memory with different protection flags.
(assuming I understood their talk correctly)
(assuming I understood their talk correctly)
Could anyone with better understanding of GC comment?