www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - About GC and implicit memory allocation.

reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
About GC and implicit memory allocation....

I've discovered this document
http://www.cs.umass.edu/~emery/pubs/04-17.pdf

----------------------------------------------------------------
Automatic vs. Explicit Memory Management:
Settling the Performance Debate

Matthew Hertz and Emery D. Berger
Dept. of Computer Science
University of Massachusetts

Conclusion:
<citation>
... we execute a range of unaltered
Java benchmarks using both garbage collection and explicit
memory management. Comparing runtime, space consumption,
and virtual memory footprints, we find that when space is plentiful,
the runtime performance of garbage collection can be competitive
with explicit memory management, and can even outperform
it by up to 4%. We find that copying garbage collection can
require six times the physical memory as the Lea or Kingsley allocators
to provide comparable performance. We also show that garbage
collection suffers orders-of-magnitude performance penalties
when paging occurs. This first-ever comparison of explicit memory
management and copying garbage collection shows where garbage
collectionmust improve in the future. While we expect the incorporation
of L3 caches to minimize the impact of garbage collection's
poor L2 locality, the relative cost of disk latency continues to grow.
Improving the space efficiency and page-level locality of garbage
collection will thus become increasingly important.
</citation>
------------------------------------------------------------
My resume:

Current implementation of memory management
in D (mix of heap and GC schemas) is just good as
it allows to benefit from both worlds.

IMHO: future direction in D memory managment
might be in implementation of memory pools. Like in Apache and Subversion.
http://scm.sipfoundry.org/svndoc/ch08s05.html

I think if we will be able to say in future:

new(myGenerationalMemoryPoolN1) MyObject;
new(myMarkAndSweepMemoryPoolN2) MyObject;
new MyObject.

then it will be just perfect. Developers will be able
to choose proper allocation schema for particular
modules, classes and objects. Dream.

Andrew.
http://terrainformatica.com
May 08 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 IMHO: future direction in D memory managment
 might be in implementation of memory pools. Like in Apache and Subversion.
 http://scm.sipfoundry.org/svndoc/ch08s05.html


Currently the closest D comes is the mark/release technique outlined in 
http://www.digitalmars.com/d/memory.html#markrelease
But that technique request cooperation by the classes being allocated. Since 
allocators are inherited one way to organize things is to have something 
like
  class PoolObject {
    new(uint s, Pool p) {... get memory from pool P ...}
    delete(void* p) {} // ignore since the pool will free it
  }
Then anything that wants to be managed by a Pool will have to subclass 
PoolObject instead of Object. Or maybe new() and delete() can be mixed in... 
It would be fun to experiment with this stuff.


 I think if we will be able to say in future:

 new(myGenerationalMemoryPoolN1) MyObject;
 new(myMarkAndSweepMemoryPoolN2) MyObject;
 new MyObject.

 then it will be just perfect. Developers will be able
 to choose proper allocation schema for particular
 modules, classes and objects. Dream.


agreed - that would be very cool.
May 08 2005
parent Valéry <Valéry_member pathlink.com> writes:
In article <d5mjn5$2um8$1 digitaldaemon.com>, Ben Hinkle says...

 IMHO: future direction in D memory managment
 might be in implementation of memory pools. Like in Apache and Subversion.
 http://scm.sipfoundry.org/svndoc/ch08s05.html


Currently the closest D comes is the mark/release technique outlined in 
http://www.digitalmars.com/d/memory.html#markrelease
But that technique request cooperation by the classes being allocated. Since 
allocators are inherited one way to organize things is to have something 
like
  class PoolObject {
    new(uint s, Pool p) {... get memory from pool P ...}
    delete(void* p) {} // ignore since the pool will free it
  }
Then anything that wants to be managed by a Pool will have to subclass 
PoolObject instead of Object. Or maybe new() and delete() can be mixed in... 
It would be fun to experiment with this stuff.


What puts me off with custom new's is that you can't use them for arrays : if
your class has an array member, you end up with the class itself in the pool and
all the rest (often the largest part) on the heap.

And of course, they don't work with structs either.
May 10 2005