5 ms·

I hope you realize that malloc is far from free in a non-GC world right? (In a GC world allocating is just moving a pointer forward.) You pay the cost somewhere

I hope you realize that malloc is far from free in a non-GC world right? (In a GC world allocating is just moving a pointer forward.) You pay the cost somewhere. The CLR has also done a lot of GC work to enable concurrent GC, thread-local heaps, and "zero pause" (in reality extremely low constant time pauses). The only way to avoid paying the cost for managing memory is to allocate everything you need once and never release it.

strictfp 11y ago
"malloc is far from free". Hehe. Pun intended? I always thought that malloc was further from free with GC :P
physguy1123 11y ago
I hope you realize that stack allocation can replace a lot of allocation that would be done by a GC? And that having control over memory layout can lend itself to better performance? And that naively mallocing everywhere is not the only or fastest way to manually manage memory, and sometimes isn't even the easiest.
- giovannibajo1 11y ago
  Go also has stack allocations for objects based on escape analysis; basically, if the compiler can prove that a variable doesn't escape, it is allocated on the heap, otherwise on the heap. Improvement on escape analysis in the compiler thus reduce also the heap size by allocating more things onto the stack.
- tokenrove 11y ago
  Many GC'd languages also have stack allocation (see dynamic-extent in Common Lisp, for example); when talking about GC vs malloc (already an over-simplified dichotomy), we should be talking about heap allocations of indefinite extent.
- pjmlp 11y ago
  Many GC languages have stack and global static memory allocation as well. Go being one of them. Others, Oberon family of languages, Modula-3, D, Eiffel and even .NET to a certain extent. Having managed heap doesn't mean other allocation types aren't available.
joosters 11y ago
Too true! I've written a couple of different mallocs before, and I'd recommend it as a project to anyone who thinks malloc() is just a simple, lightweight operation. It's not an either/or choice though, picking malloc or GC. There is a whole spectrum of allocation styles you can do that might be better for a particular application. For example, a server could use per-request memory pools, which effectively can turn related mallocs into a 'move the pointer forward' operation and the whole lot can be free()d together. I'm not saying GC is worthless. I just have a distaste for GC because it doesn't truly deliver on the promise of removing worries about memory management. You still pay the cost and can be tripped up by nasty GC performance. Even worse, the garbage collector behaviour can change between language versions and a well-tested application can suddenly hit dire performance problems. Once you have to consider GC problems, IMO you might well be better off doing old fashioned app-controlled memory allocation.
Manishearth 11y ago
> In a GC world allocating is just moving a pointer forward. which is usually for short lived objects only, and in a non-GC world these get put on the stack anyway.

strictfp 11y ago

"malloc is far from free". Hehe. Pun intended? I always thought that malloc was further from free with GC :P

physguy1123 11y ago

I hope you realize that stack allocation can replace a lot of allocation that would be done by a GC? And that having control over memory layout can lend itself to better performance? And that naively mallocing everywhere is not the only or fastest way to manually manage memory, and sometimes isn't even the easiest.

giovannibajo1 11y ago
Go also has stack allocations for objects based on escape analysis; basically, if the compiler can prove that a variable doesn't escape, it is allocated on the heap, otherwise on the heap. Improvement on escape analysis in the compiler thus reduce also the heap size by allocating more things onto the stack.
tokenrove 11y ago
Many GC'd languages also have stack allocation (see dynamic-extent in Common Lisp, for example); when talking about GC vs malloc (already an over-simplified dichotomy), we should be talking about heap allocations of indefinite extent.
pjmlp 11y ago
Many GC languages have stack and global static memory allocation as well. Go being one of them. Others, Oberon family of languages, Modula-3, D, Eiffel and even .NET to a certain extent. Having managed heap doesn't mean other allocation types aren't available.

joosters 11y ago

Too true! I've written a couple of different mallocs before, and I'd recommend it as a project to anyone who thinks malloc() is just a simple, lightweight operation. It's not an either/or choice though, picking malloc or GC. There is a whole spectrum of allocation styles you can do that might be better for a particular application. For example, a server could use per-request memory pools, which effectively can turn related mallocs into a 'move the pointer forward' operation and the whole lot can be free()d together. I'm not saying GC is worthless. I just have a distaste for GC because it doesn't truly deliver on the promise of removing worries about memory management. You still pay the cost and can be tripped up by nasty GC performance. Even worse, the garbage collector behaviour can change between language versions and a well-tested application can suddenly hit dire performance problems. Once you have to consider GC problems, IMO you might well be better off doing old fashioned app-controlled memory allocation.

Manishearth 11y ago

> In a GC world allocating is just moving a pointer forward. which is usually for short lived objects only, and in a non-GC world these get put on the stack anyway.