Linked by kragil on Wed 23rd Jan 2013 20:26 UTC
Thread beginning with comment 550426
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
More Features »
Sponsored Links



Member since:
2005-07-08
Also, given that you control exactly which memory is to be released back at any specific time, you can limit the non-deterministic impact of the 'free' call.
You think that you control when memory is returned.
Actually what happens in most languages with manual memory management is that you release the memory in the language runtime, but the runtime does not release it back to the operating system. There are heuristics in place to only return memory in blocks of certain size.
Additionally depending how you allocate/release memory you can have issues with memory fragmentation.
So in the end you end up having as much control as with a GC based language.
This is why in memory critical applications, developers end up writing their own memory manager.
But these are very special cases, and in most system languages with GC, there are also mechanisms available to perform that level of control if really needed.
So you get the memory safety of using a GC language, with the benefit to control the memory if you really need to.
As a side note, reference counting is also GC in computer science speak and with it you also get determinist memory usage.