Array Capacity Field

[Sean Kelly]

Pontus Pihlgren wrote:
> 
>> This is somewhat of a different issue.  The Phobos GC never returns 
>> any memory to the OS.  
> 
> This is my absolute favourite pet peeve with Perl, it has the same 
> behaviour.
> 
> I'm working on a fairly large program which is used on a cluster system 
> with several instances going at the same time. It is initially uses 
> quite a bit of memory (a few hundred megabytes) but then releases a 
> large part of it and lingers in this state for quite some time (waiting 
> for other processes), but from the systems point of view it never 
> decreases in size.
> 
> I realize that the GC is trying to be nice to me and speed up new 
> allocs, but I would like to force it to release memory to the system. Is 
> this possible in Phobos or Tango, it really should be?

The Tango GC actually does release memory back to the OS in some 
situations, which is why Tango doesn't explode on the example in this 
thread.  It also actually implements GC.minimize(), which I believe is a 
no-op in Phobos.  However, it's not always easy to return memory to the 
OS given the design of the GC in Phobos (which Tango inherited and 
simply modified).  Basically, memory is obtained from the OS is large 
pools and then chunks of these pools are designated as free space for 
different sized blocks as needed.  So to return a pool to the OS (by far 
the easiest approach), the entire pool must obviously be free.  The 
problem is that the chance that a pool may have at least one chunk used 
for some existing memory block is pretty high in most situations. 
However, sufficiently large single allocations (like the 15_000_000 uint 
array) are given their own pool by the GC, so when this array is 
collected it's possible to return its pool to the OS immediately.  This 
is basically what Tango does, and is likely why it doesn't crash on this 
sample app.


Sean