Name: Anonymous 2011-08-23 14:26
Why Garbage Collection is Bad as proven by Amdahl's Law
An excerpt from the Flow Language Manifesto
The fact that Flow eliminates the need for garbage collection and also eliminates the need for manual memory management (malloc/free or new/delete) is actually a very big deal. Just as programmers are extremely bad at writing multithreaded code and having it be maximally efficient and bug-free, so too are programmers bad at managing their own memory -- but garbage collection is only a halfbaked improvement over manual memory management, and it can turn into a crutch that programmers simply rely upon rather than understanding the nuances involved, and this can lead to serious memory leak issues.
Garbage collection was a helpful small evolutionary step in programming language design. However we need to move on to something better -- and the only truly better solution is precise implicit memory allocation and deallocation, as provided by Flow.
Garbage collection does not solve memory leak issues. As any Java programmer knows, it is trivially easy to hold a reference to a large object that is no longer needed for an arbitrarily long period of time, but the JVM has no way of predicting if any given referenced object might conceivably be used again at some point in the future.
In particular, if you allocate a large object in a certain scope, and then you're done using it, in Java and in a lot of other garbage-collected languages, the reference to the object is still in the local stack frame, so until that stack frame exits the garbage collector will not collect the value. This is particularly bad in data pipeline programming, where a lot of data transformations are typically implemented in the same scope, and memory hangs around a lot longer than is needed.
In fact if you are dealing with large data objects in Java, you have to manually set all references to them to null when you are finished with them if the references aren't immediately going to go out of scope. This may as well be manual memory management, it's basically the same as an explicit free/delete. However as with manually freeing a pointer in C, where the pointer stays in scope, in Java, a reference you have set to null also stays in scope, and if you later go back and modify your code and accidentally add some code below where you set the variable to null that makes use of the variable again, you'll get a NullPointerException. With Flow, right after the last thing that could ever use an object uses it, it is automatically freed.
Garbage collection also does not solve the need for manual memory allocation, which creates lots of boilerplate code -- e.g. when you create an ArrayList<ArrayList<String>> of specified dimensions, you need to iterate through and allocate the outer and each of the inner ArrayList objects yourself. Just adding Garbage collection to a language does not obviate the need for manual memory management.
GC latency can be large and unpredictable -- on the order of tens of seconds per GC on a machine with tens of gigabytes of memory. Google refuses to use Java for mission-critical core infrastructure for this reason.
GC generally also locks up all threads in the VM while one thread runs the garbage collector, which is becoming a bigger and bigger problem on today's multicore machines. Multithread-capable garbage collectors in the JVM are still viewed as experimental and are not on by default.
An excerpt from the Flow Language Manifesto
The fact that Flow eliminates the need for garbage collection and also eliminates the need for manual memory management (malloc/free or new/delete) is actually a very big deal. Just as programmers are extremely bad at writing multithreaded code and having it be maximally efficient and bug-free, so too are programmers bad at managing their own memory -- but garbage collection is only a halfbaked improvement over manual memory management, and it can turn into a crutch that programmers simply rely upon rather than understanding the nuances involved, and this can lead to serious memory leak issues.
Garbage collection was a helpful small evolutionary step in programming language design. However we need to move on to something better -- and the only truly better solution is precise implicit memory allocation and deallocation, as provided by Flow.
Garbage collection does not solve memory leak issues. As any Java programmer knows, it is trivially easy to hold a reference to a large object that is no longer needed for an arbitrarily long period of time, but the JVM has no way of predicting if any given referenced object might conceivably be used again at some point in the future.
In particular, if you allocate a large object in a certain scope, and then you're done using it, in Java and in a lot of other garbage-collected languages, the reference to the object is still in the local stack frame, so until that stack frame exits the garbage collector will not collect the value. This is particularly bad in data pipeline programming, where a lot of data transformations are typically implemented in the same scope, and memory hangs around a lot longer than is needed.
In fact if you are dealing with large data objects in Java, you have to manually set all references to them to null when you are finished with them if the references aren't immediately going to go out of scope. This may as well be manual memory management, it's basically the same as an explicit free/delete. However as with manually freeing a pointer in C, where the pointer stays in scope, in Java, a reference you have set to null also stays in scope, and if you later go back and modify your code and accidentally add some code below where you set the variable to null that makes use of the variable again, you'll get a NullPointerException. With Flow, right after the last thing that could ever use an object uses it, it is automatically freed.
Garbage collection also does not solve the need for manual memory allocation, which creates lots of boilerplate code -- e.g. when you create an ArrayList<ArrayList<String>> of specified dimensions, you need to iterate through and allocate the outer and each of the inner ArrayList objects yourself. Just adding Garbage collection to a language does not obviate the need for manual memory management.
GC latency can be large and unpredictable -- on the order of tens of seconds per GC on a machine with tens of gigabytes of memory. Google refuses to use Java for mission-critical core infrastructure for this reason.
GC generally also locks up all threads in the VM while one thread runs the garbage collector, which is becoming a bigger and bigger problem on today's multicore machines. Multithread-capable garbage collectors in the JVM are still viewed as experimental and are not on by default.