General Problems for GC'ed Applications?

[Tommie Gannert]

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.
> 
> 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.
> 
> 3) If there is more than one GC'ed application running, those 
> applications compete for the available main memory.
> 

Just a philosophical thought:

Perhaps we should look at the GC as a RAD tool for initial development,
and that the goal is to replace it with manual memory management (M3?).
Then you could do it piece by piece, this might be attractive to two 
types of coders.

  Corporate coders in the need of quick deliveries, but without much
  performance issues (because they can always tell the customer to
  buy new hardware...)

  Performance coders doing alpha blending a billion times per second.
  Their first priority would be to use the GC as little as possible.

To aid in M3, some way of tracking allocations would be needed. Maybe
a program like coverage or profiling, where you could see which 
allocations are (most often) freed by the GC and which are manually
deallocated. This would probably appeal to a third kind of people:

  Academical coders who wants everything to be proven, but does not feel
  they have the time to write deallocating calls as priority one. But
  they are driven by the urge, or feeling, that beautiful code is code
  that does not depend on GC and does not leak memory.

</philosophy>