Garbage Collection
closed account (S6k9GNh0)
D and Go is forcing a default garbage collector onto its users. Java, Python, Perl, and various other languages use one as well most having very serious early (and current) problems.
What is everyone's opinions on such a matter? I've seen benchmarks heading towards manual allocation and de-allocation. I don't think I've seen the other way around and I'd really like to see that side. GCC uses a garbage collector, various commercial and large open-source projects use garbage collectors. I see a lot of statements of stability and an assurance of efficiency in a *good* garbage collector but not a lot to back up those claims.
http://www.jwz.org/doc/gc.html
http://www.airs.com/blog/archives/185
http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
What is everyone's opinions on such a matter? I've seen benchmarks heading towards manual allocation and de-allocation. I don't think I've seen the other way around and I'd really like to see that side. GCC uses a garbage collector, various commercial and large open-source projects use garbage collectors. I see a lot of statements of stability and an assurance of efficiency in a *good* garbage collector but not a lot to back up those claims.
http://www.jwz.org/doc/gc.html
http://www.airs.com/blog/archives/185
http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
Last edited on
Programming with GC is a much different thing than programming without it. For example some problems get very hairy and complex when implemented without support from GC (e.g. compilers, graph algorithms) and some are near to impossible (functional programming is a great example of that).
As for performance, applications with GC have much *different* performance characteristics than applications without it. It means, it is wrong to ask question "what is faster". For example allocation of short-lived objects is extremely cheap. It is also easy to prove GC is generally faster than manual dynamic memory management if only enough memory is available, however the location of exact crossing point depends on the application. Additionally you can move GC to another thread and do it asynchronously on a spare CPU core. Usually for memory-scarce systems (e.g. embedded) or hard real time systems I'd use manual memory allocation and for general purpose programming / soft realtime, where plenty of memory is available, GC is the way to go.
Comparing different GCs is another topic. These for C++, D or Go stand no chance compared to these used by languages run on the VM.
As for performance, applications with GC have much *different* performance characteristics than applications without it. It means, it is wrong to ask question "what is faster". For example allocation of short-lived objects is extremely cheap. It is also easy to prove GC is generally faster than manual dynamic memory management if only enough memory is available, however the location of exact crossing point depends on the application. Additionally you can move GC to another thread and do it asynchronously on a spare CPU core. Usually for memory-scarce systems (e.g. embedded) or hard real time systems I'd use manual memory allocation and for general purpose programming / soft realtime, where plenty of memory is available, GC is the way to go.
Comparing different GCs is another topic. These for C++, D or Go stand no chance compared to these used by languages run on the VM.
Last edited on
I would prefer if the programmers of D and Go which I understand to be tending toward being lower level languages had a choice. I can understand why Perl, Python, and Java have garbage collection, though.
-Albatross
-Albatross
I don't know how D, but Go's compiler currently creates awfully slow code, and GC is probably their last problem. It is definitely *not* usable for low-level stuff.
Last edited on
Well, that would be a problem, now, wouldn't it? Maybe they should have spent less time on implementing a GC mechanism and more on optimizing their compiler... ;)
-Albatross
-Albatross
Last edited on
Don't modern operating systems provide builtin "garbage collection" anyway?
I'll expose my ignorance, by saying that I don't understand what "garbage" is supposed to mean.
If you define it to be unused data, I see no reason why the OS itself can't deal with it.
I'll expose my ignorance, by saying that I don't understand what "garbage" is supposed to mean.
If you define it to be unused data, I see no reason why the OS itself can't deal with it.
I'm pretty sure "garbage" here refers to dynamically-allocated memory on the heap that wasn't freed after the program was closed.
-Albatross
-Albatross
Garbage means memory that is dynamically allocated but not being used.
Garbage collectors automatically free dynamically allocated memory that is not being used whenever the platform (e.g., the Java VM or .Net CLI, or the OS if it has a garbage collector) decides to run the collector (which is non-deterministic because it could decide to run it at any point, usually there isn't a set interval). The operating system could do that itself but I don't know of one that does (Android does something similar). You could probably write a Linux kernel module to do it (which I might try).
The OS only cleans up memory when a program exits which isn't really garbage collection.
@Albatross,
If the program is still running, any unused heap memory is still classed as garbage. That's why the OS can't be considered a garbage collector - it doesn't free memory until the program exits or it is freed manually.
Garbage collectors automatically free dynamically allocated memory that is not being used whenever the platform (e.g., the Java VM or .Net CLI, or the OS if it has a garbage collector) decides to run the collector (which is non-deterministic because it could decide to run it at any point, usually there isn't a set interval). The operating system could do that itself but I don't know of one that does (Android does something similar). You could probably write a Linux kernel module to do it (which I might try).
The OS only cleans up memory when a program exits which isn't really garbage collection.
@Albatross,
If the program is still running, any unused heap memory is still classed as garbage. That's why the OS can't be considered a garbage collector - it doesn't free memory until the program exits or it is freed manually.
Last edited on
I am using C++ because it has no garbage collection. There's no place for that in the world of hard real-time.
Of course now that C++ supports mark-sweep GC (not mark-compact, thankfully, which would be impossible anyway), things may get more interesting, once the compilers catch up.
Of course now that C++ supports mark-sweep GC (not mark-compact, thankfully, which would be impossible anyway), things may get more interesting, once the compilers catch up.
closed account (S6k9GNh0)
Catfish, what chrisname said. In example Firefox, the web browser, can stay open for several hours. Each time you fail to de-allocate an allocated block of data, the memory consumption increases which can also increase potential security threats and stability in general.
rapidcoder, Java is often seen to be slow during memory collection. Java applications apparently have a memory model that goes by the lines of: allocate memory, wait till it reaches near its peak memory usage, collect allocations at once. If I'm not mistaken, it actually interrupts the program to do this by default as well.
I can understand in a interpreted scripted language like Python. They're used for both trivial and cumbersome tasks but generally not for performance. Java on the other hand is often boasted for its comparison of speed to SP languages such as C and C++.
I see garbage collector advocates boast things like "smaller memory usage through compression techniques and other things", "faster de-allocations", and "safety". So far, I've only seen the safety part and even then, I've seen Java server applications strangle themselves of resources causing a very obvious security problem. Is Java just a bad example?
Really, I want to be believe in garbage collection, it would make my life a little bit easier. But every time I argue with someone, I get claims that they can't backup. Where is this lower memory usage with a garbage collector? Where are the sped up benchmarks? I find these claims *a lot* but nothing to prove them.
I can understand in very large projects where memory becomes very complicated. But anything underneath that and I lose sight of the point.
rapidcoder, Java is often seen to be slow during memory collection. Java applications apparently have a memory model that goes by the lines of: allocate memory, wait till it reaches near its peak memory usage, collect allocations at once. If I'm not mistaken, it actually interrupts the program to do this by default as well.
I can understand in a interpreted scripted language like Python. They're used for both trivial and cumbersome tasks but generally not for performance. Java on the other hand is often boasted for its comparison of speed to SP languages such as C and C++.
I see garbage collector advocates boast things like "smaller memory usage through compression techniques and other things", "faster de-allocations", and "safety". So far, I've only seen the safety part and even then, I've seen Java server applications strangle themselves of resources causing a very obvious security problem. Is Java just a bad example?
Really, I want to be believe in garbage collection, it would make my life a little bit easier. But every time I argue with someone, I get claims that they can't backup. Where is this lower memory usage with a garbage collector? Where are the sped up benchmarks? I find these claims *a lot* but nothing to prove them.
I can understand in very large projects where memory becomes very complicated. But anything underneath that and I lose sight of the point.
Last edited on
| computerquip wrote: |
|---|
| Firefox, the web browser, can stay open for several hours |
If you wanted an example of low memory usage or good memory management, Firefox was the wrong one :P The codebase for Firefox is horrible due to things like feature creep as well as its sheer size.
| computerquip wrote: |
|---|
| allocate memory, wait till it reaches near its peak memory usage, collect allocations at once |
Yes but AFAIK all garbage collectors do that. I've never heard of one that ran periodically or anything like that.
| computerquip wrote: |
|---|
| If I'm not mistaken, it actually interrupts the program to do this by default as well |
Again, near-enough all garbage collectors do that. You could do GC in a separate thread like rapidcoder said but if it's all in one thread (or if every thread has it's own GC) then the program has to be interrupted.
closed account (S6k9GNh0)
Firefox was used for its longevity of openess, not its memory issues lol.
Also, is claiming a GC that does the same thing as most GCs supposed to be a good thing?
If every more modern language is moving towards garbage collection then why not let the OS have a hand in it since it handles allocations in the first place?
Also, is claiming a GC that does the same thing as most GCs supposed to be a good thing?
If every more modern language is moving towards garbage collection then why not let the OS have a hand in it since it handles allocations in the first place?
| computerquip wrote: |
|---|
| Also, is claiming a GC that does the same thing as most GCs supposed to be a good thing? |
No, it was supposed to demonstrate that the Java GC is no better or worse than any other GC.
| computerquip wrote: |
|---|
| If every more modern language is moving towards garbage collection then why not let the OS have a hand in it since it handles allocations in the first place? |
It's not that no-one will "let" the OS handle GC, it's that no OS (that I know of) currently does handle it.
IMO implementing a GC in the OS, while interesting, would be a bad idea:
1. It encourages people not to deallocate memory, which needs to be fixed when porting to an operating system that lacks GC (a GC as part of the language doesn't have this problem because the GC is still there when you port to a new system)
2. It's slow - you say GC is slow enough when it's a single program being collected, but you want an entire system to have GC? For the average computer that means searching around 1 GB of memory, often more, for references to every single object. And on a server or a cluster... you'd potentially be searching tens, hundreds or even thousands of gigabytes of memory.
3. Some programs might not want GC enabled if it interferes with things (though you could have an API for programs to request that the OS lets them handle their own memory)
4. A garbage collector is just another vector for complexity (and bugs) to enter an already over-complex operating system (which virtually all of them are, although MINIX is very well-organised and the FreeBSD kernel is pretty neat).
Last edited on
closed account (S6k9GNh0)
I never said it was viable, I was saying if every modern language forces the garbage collector onto people, what other outcome would there be? D is actually considering removal of the "delete" keyword. Go *I think* allows some form of malloc/free. D allows it through a C runtime. I've tried convincing people that a solution for both should be made but I've been explicitly told that the GC has "succeded explicit memory management".
Am I missing the big picture here?
btw, I think I'm done with D. They say and do too many things that piss me off... for instance, they're thinking of removing ordered parameters and using parameters similar to Pythons. This is terrible for any partially low-level language thus D has been taken off my list of viable SP languages...
Am I missing the big picture here?
btw, I think I'm done with D. They say and do too many things that piss me off... for instance, they're thinking of removing ordered parameters and using parameters similar to Pythons. This is terrible for any partially low-level language thus D has been taken off my list of viable SP languages...
Last edited on
@ chrisname (no disrespect intended):
1. Meh, this ain't the 90s anymore. Backward compatibility is useful, for a time, up to a point, after which dropping it becomes beneficial.
2. It'd be a very naive implementation to just search blindly without any hints. (I may still think of GC the wrong way?)
3. Valid point. But it'd take a lot of rebellious programmers for that to be an issue.
4. Who cares, let the OS developers deal with it, so we don't have to. I'd rather have them work on that feature, than say DRM.
@ computerquip: Your latest post inspired me to start a possible flamewar thread, as I don't wish to derail this one.
1. Meh, this ain't the 90s anymore. Backward compatibility is useful, for a time, up to a point, after which dropping it becomes beneficial.
2. It'd be a very naive implementation to just search blindly without any hints. (I may still think of GC the wrong way?)
3. Valid point. But it'd take a lot of rebellious programmers for that to be an issue.
4. Who cares, let the OS developers deal with it, so we don't have to. I'd rather have them work on that feature, than say DRM.
@ computerquip: Your latest post inspired me to start a possible flamewar thread, as I don't wish to derail this one.
1. It's not backwards compatibility, it's more like "sideways" compatibility, i.e., portability between different OSes
2. True
4. Disagree, although I dislike DRM too.
2. True
4. Disagree, although I dislike DRM too.
@moorecm
You obviously have never tried Fedora. No offense. :/
-Albatross
You obviously have never tried Fedora. No offense. :/
-Albatross
Last edited on
closed account (3hM2Nwbp)
The makers of any language that uses garbage collection had better plan for it better than Sun/Oracle did. I definitely recommend watching the seminar below on garbage collection. "Big Evil Corporation" haters beware, it's a presentation by Azul Systems on how they solved the responsiveness issue with the Java collectors.
* http://www.infoq.com/presentations/Java-without-the-GC-Pauses - it's about 80 minutes long.
Come on...
who needs more than 512kb anyway? --> 10 years pass
'' '' 100MB anyway? --> 10 years pass
" " 1GB anyway?
" " 1TB anyway?
* http://www.infoq.com/presentations/Java-without-the-GC-Pauses - it's about 80 minutes long.
Come on...
who needs more than 512kb anyway? --> 10 years pass
'' '' 100MB anyway? --> 10 years pass
" " 1GB anyway?
" " 1TB anyway?