4 ms·

If one has to worry about allocating or not allocating objects on the heap, what is the difference between worrying about memory management that way (and suffer

by Annatar 11y ago

If one has to worry about allocating or not allocating objects on the heap, what is the difference between worrying about memory management that way (and suffering memory consumption and performance because of the garbage collector), and doing memory management manually with alloca(3C) or malloc(3C) in C, and having pretty much guaranteed performance???

panic 11y ago
Well, when you use a GC, you don't have to figure out where to put the "free" calls. This sounds like a minor thing, but it lets you write code in a very different style (have you ever tried writing a functional program with explicit malloc and free?) That said, there are other ways to avoid writing "free" than using a garbage collector. Regions (https://en.wikipedia.org/wiki/Region-based_memory_management https://en.wikipedia.org/wiki/Region-based_memory_management) are faster at allocation than malloc (you just increment a pointer to allocate) and faster at freeing than a GC (you throw away the entire region when you're done with it). It seems tricky to base a general-purpose programming language around them, though.
- Annatar 11y ago
  > Well, when you use a GC, you don't have to figure out where to put the "free" calls. That is precisely why I mentioned alloca(3C): it automatically frees the memory for you, if you do not want to do it yourself. From the Solaris / illumos alloca(3C) manual page: void *alloca(size_t size); The alloca() function allocates size bytes of space in the stack frame of the caller, and returns a pointer to the allocated block. This temporary space is automatically freed when the caller returns. If the allocated block is beyond the current stack limit, the resulting behavior is unde- fined. > (have you ever tried writing a functional program with explicit malloc and free?) I got my start on MOS 6502 / MOS 6510 / MC68000 assembler, so for me making malloc(3C) and free(3C) calls when programming in a functional style is completely normal. I have no problem with that whatsoever.
  - panic 11y ago
    The part where behavior is undefined when you overflow the stack makes alloca difficult to use safely, but it is very nice when you can use it! Did you write your 6502 code with closures, higher-order functions, and so on? My point is that can be hard to figure out when to free an object in this kind of environment, where a value can be captured by multiple closures and may not have a clear owner.
    - Annatar 11y ago
      Then either use C and manually manage memory, or use ANSI common LISP, and no problem.
  - the_why_of_y 11y ago
    If the allocated block is beyond the current stack limit, the resulting behavior is unde- fined. And you even quoted the part that hints at why alloca(3C) is so rarely used in practice: you get a pointer result, but you have no way of knowing if it's actually safe to use it.
    - Annatar 11y ago
      This should tell one whether the pointer returned by alloca(3C) is safe to use: #include <sys/time.h> #include <sys/resource.h> #include <stdio.h> int main(int argc, char *argv[]) { struct rlimit limit; getrlimit(RLIMIT_STACK, &limit); printf("Stack start at %p, end at %p.\n", &argc, &argc - limit.rlim_cur); return(0); } % cc limit.c -o limit && ./limit Stack start at 0x7fff51094ba8, end at 0x7fff4f094ba8. If the pointer returned by alloca(3C) is within those memory addresses, and does not exceed the bottom (in this example, $7fff4f094ba8), it is safe to use.
_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 Annatar 11y ago

panic 11y ago

Well, when you use a GC, you don't have to figure out where to put the "free" calls. This sounds like a minor thing, but it lets you write code in a very different style (have you ever tried writing a functional program with explicit malloc and free?) That said, there are other ways to avoid writing "free" than using a garbage collector. Regions (https://en.wikipedia.org/wiki/Region-based_memory_management https://en.wikipedia.org/wiki/Region-based_memory_management) are faster at allocation than malloc (you just increment a pointer to allocate) and faster at freeing than a GC (you throw away the entire region when you're done with it). It seems tricky to base a general-purpose programming language around them, though.

Annatar 11y ago
> Well, when you use a GC, you don't have to figure out where to put the "free" calls. That is precisely why I mentioned alloca(3C): it automatically frees the memory for you, if you do not want to do it yourself. From the Solaris / illumos alloca(3C) manual page: void *alloca(size_t size); The alloca() function allocates size bytes of space in the stack frame of the caller, and returns a pointer to the allocated block. This temporary space is automatically freed when the caller returns. If the allocated block is beyond the current stack limit, the resulting behavior is unde- fined. > (have you ever tried writing a functional program with explicit malloc and free?) I got my start on MOS 6502 / MOS 6510 / MC68000 assembler, so for me making malloc(3C) and free(3C) calls when programming in a functional style is completely normal. I have no problem with that whatsoever.
- panic 11y ago
  The part where behavior is undefined when you overflow the stack makes alloca difficult to use safely, but it is very nice when you can use it! Did you write your 6502 code with closures, higher-order functions, and so on? My point is that can be hard to figure out when to free an object in this kind of environment, where a value can be captured by multiple closures and may not have a clear owner.
  - Annatar 11y ago
    Then either use C and manually manage memory, or use ANSI common LISP, and no problem.
- the_why_of_y 11y ago
  If the allocated block is beyond the current stack limit, the resulting behavior is unde- fined. And you even quoted the part that hints at why alloca(3C) is so rarely used in practice: you get a pointer result, but you have no way of knowing if it's actually safe to use it.
  - Annatar 11y ago
    This should tell one whether the pointer returned by alloca(3C) is safe to use: #include <sys/time.h> #include <sys/resource.h> #include <stdio.h> int main(int argc, char *argv[]) { struct rlimit limit; getrlimit(RLIMIT_STACK, &limit); printf("Stack start at %p, end at %p.\n", &argc, &argc - limit.rlim_cur); return(0); } % cc limit.c -o limit && ./limit Stack start at 0x7fff51094ba8, end at 0x7fff4f094ba8. If the pointer returned by alloca(3C) is within those memory addresses, and does not exceed the bottom (in this example, $7fff4f094ba8), it is safe to use.

_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).