View Single Post
Posts: 1,341 | Thanked: 708 times | Joined on Feb 2010
#165
Read for example this:
http://en.wikipedia.org/wiki/Garbage...vs._non-moving
At first, a moving GC strategy may seem inefficient and costly compared to the non-moving approach, since much more work would appear to be required on each cycle. In fact, however, the moving GC strategy leads to several performance advantages, both during the garbage collection cycle itself and during actual program execution:

* No additional work is required to reclaim the space freed by dead objects; the entire region of memory from which reachable objects were moved can be considered free space. In contrast, a non-moving GC must visit each unreachable object and somehow record that the memory it alone occupied is available.
* Similarly, new objects can be allocated very quickly. Since large contiguous regions of memory are usually made available by the moving GC strategy, new objects can be allocated by simply incrementing a 'free memory' pointer. A non-moving strategy may, after some time, lead to a heavily fragmented heap, requiring expensive consultation of "free lists" of small available blocks of memory in order to allocate new objects.
* If an appropriate traversal order is used (such as cdr-first for list conses), objects that refer to each other frequently can be moved very close to each other in memory, increasing the likelihood that they will be located in the same cache line or virtual memory page. This can significantly speed up access to these objects through these references.
And in all OOP-programs which have many variable size variable life time objects, you cannot really archive both high object locality and small fragmentation ratio, unless you use some kind of "moving-GC".

The usefull method to try to keep heap memory fragmentation small, is to use different memory pools for different sizes of objects, but with that method you easily loose the locality of the objects and get more pagefaults because in some hotspot needed objects are scattered around in different memory pools.

I wonder have you really read the URIs given in the start of this thread where they talk about opimizing VM, GC and why eventually Java can (and will) be faster than C++.