4 ms·

The difference is, that reviewing your memory allocation is a matter of program performance, not of program correctness. And you don't have to do it everywhere.

by _ph_ 11y ago

The difference is, that reviewing your memory allocation is a matter of program performance, not of program correctness. And you don't have to do it everywhere. Just make sure that in the hot spots of your program there is not excessive heap allocation. The benefit of GC is the correctness you get by never having to call free() and the drastic simplification of all program parts which do have to alloc memory. In C, for anything that does get allocated on the heap, you have to carefully observe who is in charge of deallocating it later in the programs lifetime and to make sure that there are no pointers to it left. GC will take this complexity out of your program, which can make a lot of code much simpler.

Annatar 11y ago
The thing is, the garbage collector often does not. Where I currently work, we have Java applications which use 300 GB of memory. To me as an assembler coder, that is so wrong on so many levels. If we were doing a finite element analysis with a 100 million by 100 million matrix calculation in order to compute the cavitation inside of a nuclear reactor (and even that software, written in Fortran, didn't need more than a few GB!), I could (perhaps) understand, but we're not doing anything even remotely close to that.
- _ph_ 11y ago
  Right, but that problem ist mostly Java, and less so GC. Java pretty much forces you to allocate everything on the heap, there are no value types in Java, and most Java libraries tend to be complex and heap-heavy. We have here a web site run by tomcat which takes like 4 gb of real memory, crazy! (It also does not help, that Java strings use 16 bit characters) GC languages require a certain amount of extra memory beyond the live memory as an overhead, but beyond that they should not have more impact on the memory footprint. In some use cases, this extra memory is not acceptable, but for reasonably sized applications, this is acceptable (not talking about Java here...) and the benefit is the correctness and often cleaner code (no complex protocols for object lifetime).

by _ph_ 11y ago

Annatar 11y ago

The thing is, the garbage collector often does not. Where I currently work, we have Java applications which use 300 GB of memory. To me as an assembler coder, that is so wrong on so many levels. If we were doing a finite element analysis with a 100 million by 100 million matrix calculation in order to compute the cavitation inside of a nuclear reactor (and even that software, written in Fortran, didn't need more than a few GB!), I could (perhaps) understand, but we're not doing anything even remotely close to that.

_ph_ 11y ago
Right, but that problem ist mostly Java, and less so GC. Java pretty much forces you to allocate everything on the heap, there are no value types in Java, and most Java libraries tend to be complex and heap-heavy. We have here a web site run by tomcat which takes like 4 gb of real memory, crazy! (It also does not help, that Java strings use 16 bit characters) GC languages require a certain amount of extra memory beyond the live memory as an overhead, but beyond that they should not have more impact on the memory footprint. In some use cases, this extra memory is not acceptable, but for reasonably sized applications, this is acceptable (not talking about Java here...) and the benefit is the correctness and often cleaner code (no complex protocols for object lifetime).