More radical ideas about gc and reference counting

[Xavier Bigand via Digitalmars-d]

Le 06/05/2014 08:33, Jacob Carlborg a écrit :
> On 06/05/14 08:07, HaraldZealot wrote:
>
>> I notice that I view only part of problem, can anybody link or describe
>> me completely state and problems of current garbage collection and other
>> resource management? It help me in finding of existence solution (at
>> least theoretical).
>
> The major issue with the garbage collector is that it's not guaranteed
> to run a collection. When a collection is run the GC will call the
> destructors for the objects it collects. If there's no guarantee a
> collection is run there can be no guarantee that destructors are called.
> A collection is usually run when allocating new memory and there's not
> enough memory available.
>

For me that working almost every days on mobile devices, that not a good 
thing to release the memory when there is some new allocations.

Took an application with the notion of projects, here is a classical 
sequence users will do :
  1) Launch the application
  2) Open a project (heavy load on memory)
  3) Do some modifications (adding few allocations)
  4) Switch to the an other project

Please consider those kind of restrictions (from iOS and/or Android) :
  - After memory warning if you don't release memory enough fast your 
application will be killed
  - If you lock the main thread for too much time your application will 
be killed

Now how we implement transition between step 3 and 4 :
  - Saving the current project
  - Release manually all his memory and other resources can't be easily 
shared
  - At this point we are almost sure that memory and resources 
footprints are to the minimum amount (except leaks)
  - We can load the new project and allocate memory safely

Now with the GC, we tend to saturate the memory of the device which will 
cause memory warning with a chance of crash of the application. It's 
slower than manual release cause of number of scans,...
Even on devices like PC, GC's when they don't share memory pool between 
applications tends to reduce resources for other applications (bad for 
multitask OS).
So with a GC for this kind of steps we need shutdown the GC, and force 
the collect where it's interesting.

IMO, manual management is not the best, GC neither, but with good tools 
memory issues can be easy to find and fix. Apple have great tools for 
that on iOS, their memory analyser find leaks without any performance 
slow down just like if it's supported by the hardware!!!