General Problems for GC'ed Applications?

[Dave]

Karen Lanrap wrote:
> I see three problems:
> 
> 1) The typical behaviour of a GC'ed application is to require more 
> and more main memory but not to need it. Hence every GC'ed 
> application forces the OS to diminish the size of the system cache 
> held in main memory until the GC of the application kicks in.
> 

That's a pretty big assertion - have you some evidence, particularly 
w.r.t. mark/sweep which the current D implementation uses? Have you 
looked at the current implementation to see if your assertion jives? 
Have you (well) written D applications that show this to be the case?

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=1

Yes these are trivial benchmarks, but they were not written to be 
especially memory efficient (more concerned with wall clock performance 
although of course they are often one in the same):

D does pretty well there and all of the tests use the GC.

Plus, with some form of well implemented moving/compacting collector D 
would even do better with regard to both speed and space.

The reason the implementation is important is because now when D 
requests more memory from the GC, the GC will first try to satisfy that 
request by collecting. It's not a real "greedy" allocator. So, unless a 
program is for the length of the program holding onto a lot of memory 
(e.g.: using a lot of global reference vars) then what you describe 
should not really happen that much more often than by using the crt to 
manage memory.

> 2) If the available main memory is unsufficient for the true memory 
> requirements of the application and the OS provides virtual memory 
> by swapping out to secondary storage, every run of the GC forces 
> the OS to slowly swap back all data for this application from 
> secondary storage and runs of the GC occur frequently, because main 
> memory is tight.
> 

This will and does happen, but it's no different than if you cache a 
series of large files (or whatever) in memory using space allocated by 
malloc and then repeatedly access widely different offsets of those 
chunks of memory. Actually in that case if you'd used the GC you may be 
_less_ likely to repeatedly swap. In other words, if you're judicious 
with your memory usage w/ either the GC or crt you may be as likely to 
run into the problem with either.

> 3) If there is more than one GC'ed application running, those 
> applications compete for the available main memory.
> 

Yes but if assertion #1 is not necessarily true, then malloc/free is no 
magic bullet here over a GC either (obviously).

> 
> I see four risks:
> 
> a) from 1: The overall reaction of the system gets slower in favor 
> for the GC'ed application.
> 
> b) from 2: Projects decomposed into several subtasks may face 
> severe runtime problems when integrating the independent and 
> succesful tested modules.
> 
> c) from 2 and b: The reduction of man time in the development and 
> maintenance phases for not being forced to avoid memory leaks may 
> be overly compensated by an increase of machine time by a factor of 
> 50 or more.
> 
> d) from 1 and 3: A more complicated version of the dining 
> philosophers problem is introduced. In this version every 
> philosopher is allowed to rush around the table and grab all unused 
> forks and declare them used, before he starts to eat---and nobody 
> can force him to put them back on the table.
> 
> 
> Conclusion:
> 
> I know that solving the original dining philosophers problem took 
> several years and I do not see any awareness towards this more 
> complicated version arising by using a GC.
> Risks c) and d) are true killers.
> Therefore GC'ed applications currently seem to be suitable only if 
> they are running single instance on a machine well equipped with 
> main memory and no other GC'ed applications are used.
> To assure that these conditions hold, the GC should maintain 
> statistics on the duration of its runs and frequency of calls. This 
> would allows the GC to throw an "Almost out of memory".