Draft about memory management and garbage collectors
-
This is a draft of an article I am writing. I wonder if someone would be interested in exploring the subject with me. The trouble with Memory This is only a draft. I am still working on this. If you want to give me some idea/advice on this: pascal 2007 at ganaye d0t com At the beginning there was C and C++ Memory management commands in C would typically look like this: void *q = malloc(10); free(q); And in C++ like this: MyClass * c1 = new MyClass(); delete MyClass; Bug 1 - One of the major problem with C is that there is nothing to prevent you from writing out the memory block you have allocated. This will generally result in a crash but can also have unpredictable result and can be used by hackers to run trojan horse code. In both languages we have to remember to call a command to give the memory back to the system. Bug 2 - The programmer forget to call delete. This is quite a common bug. It is commonly called a memory leak. The program uses more and more memory until but continue to work normally. At some point it can slow down significantly if too much memory is used and the computer is starting to use its swap disk. Ultimately it can crash the PC if no memory is available. Bug 3 - The programmer calls delete more than once Depending on the resilience of your system the program will either crash, or continue undisturbed. Bug 4 - The programmer calls delete but continue to use the object after it has been destroyed. This will generally result in a crash but can also have unpredictable result and can be used by hackers to run trojan horse code. Then came the garbage collected languages As it is not possible to guarantee that the programmers won't produce bugs 1 to 4, a new languages were invented in which those bug would not exist altogether. As I see it, languages like Java, C# and VB.Net were designed to eradicate completly this sort of issues. Fixing bug 1 came at a steep price. When in C or C++ you access an array there is no boundary check, whereas Java and C# will check that you don't read or write beyond the array size. Fixing bug 2, 3 and 4 came at a steep price. In Java and C# you don't need to call a destructor, and moreover not only you don't have to but you can't kill an object altogether. The object will die when it is not used and the garbage collector decides to do its clean it up. As you can't call destroy even once there is no way to call it twice. Equally as you can't call destroy, it is not possible to use an object
-
This is a draft of an article I am writing. I wonder if someone would be interested in exploring the subject with me. The trouble with Memory This is only a draft. I am still working on this. If you want to give me some idea/advice on this: pascal 2007 at ganaye d0t com At the beginning there was C and C++ Memory management commands in C would typically look like this: void *q = malloc(10); free(q); And in C++ like this: MyClass * c1 = new MyClass(); delete MyClass; Bug 1 - One of the major problem with C is that there is nothing to prevent you from writing out the memory block you have allocated. This will generally result in a crash but can also have unpredictable result and can be used by hackers to run trojan horse code. In both languages we have to remember to call a command to give the memory back to the system. Bug 2 - The programmer forget to call delete. This is quite a common bug. It is commonly called a memory leak. The program uses more and more memory until but continue to work normally. At some point it can slow down significantly if too much memory is used and the computer is starting to use its swap disk. Ultimately it can crash the PC if no memory is available. Bug 3 - The programmer calls delete more than once Depending on the resilience of your system the program will either crash, or continue undisturbed. Bug 4 - The programmer calls delete but continue to use the object after it has been destroyed. This will generally result in a crash but can also have unpredictable result and can be used by hackers to run trojan horse code. Then came the garbage collected languages As it is not possible to guarantee that the programmers won't produce bugs 1 to 4, a new languages were invented in which those bug would not exist altogether. As I see it, languages like Java, C# and VB.Net were designed to eradicate completly this sort of issues. Fixing bug 1 came at a steep price. When in C or C++ you access an array there is no boundary check, whereas Java and C# will check that you don't read or write beyond the array size. Fixing bug 2, 3 and 4 came at a steep price. In Java and C# you don't need to call a destructor, and moreover not only you don't have to but you can't kill an object altogether. The object will die when it is not used and the garbage collector decides to do its clean it up. As you can't call destroy even once there is no way to call it twice. Equally as you can't call destroy, it is not possible to use an object
Hi Pascal, FYI: nobody can edit this message but you. I read your text in fast forward, and I agree with most of what you said. Two remarks: 1. I don't think the using construct and the IDisposable interface exist or are the same in Java. 2. WeakReference class needs to be mentioned, as it alleviates some problems when implementing cache-like data structures. One criticism: I don't believe requiring an owner is wise; most objects don't really have an owner, i.e. someone creates them, uses them, passes them on, until no one is interested any more. Who owns the rooms of a house? who owns a book that you borrow? Passing ownership will soon be required, and then you can make the same mistakes with it, as you can with (not) freeing a C "object". :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
-
Hi Pascal, FYI: nobody can edit this message but you. I read your text in fast forward, and I agree with most of what you said. Two remarks: 1. I don't think the using construct and the IDisposable interface exist or are the same in Java. 2. WeakReference class needs to be mentioned, as it alleviates some problems when implementing cache-like data structures. One criticism: I don't believe requiring an owner is wise; most objects don't really have an owner, i.e. someone creates them, uses them, passes them on, until no one is interested any more. Who owns the rooms of a house? who owns a book that you borrow? Passing ownership will soon be required, and then you can make the same mistakes with it, as you can with (not) freeing a C "object". :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
Hi Luc, I am glad you answered this will help me to improve the article before it is released. > 1. I don't think the using construct and the IDisposable interface exist or are the same in Java. You're right http://java.sun.com/developer/technicalArticles/javase/finalization/[^] I guess Java programmers will have to create a Close method or have to wait for GC to fire the finalizer. 2. WeakReference class needs to be mentioned, as it alleviates some problems when implementing cache-like data structures. I will have to describe this. The weakreference is useful to let the garbage collector collect some object while still be able to access it if it has not. Weak references are not required in my system. All pointers are effectively weak references apart from the ownership. > One criticism: > I don't believe requiring an owner is wise; most objects don't really have an owner, > i.e. someone creates them, uses them, passes them on, until no one is interested any more. > Who owns the rooms of a house? who owns a book that you borrow? > Passing ownership will soon be required, and then you can make the same mistakes with it, > as you can with (not) freeing a C "object". I need to expand on this obviously. You might well be right. There are a number of potential bugs using my owner: 1 - The programmer creates every objects with the parent being the application. You're right in this scenario nothing will be freed automatically like in C. I will write a few sample in the article where objects will be created with a form as an owner. The owner could also be the current method. I will need to speak about c# stackalloc. > Who owns the rooms of a house? > who owns a book that you borrow? What you give as a parameter is what will determine the lifetime of the object. The term owner perhaps is wrong perhaps it could be called differently. Typically the owner will be your method, or your current object. In some cases it will be the collection you'll put the object in. > Passing ownership will soon be required It is indeed > and then you can make the same mistakes with it, > you can with (not) freeing a C "object". Yes you will have the same C issue here but not some of the worse issues that causes crashes. I will expand this further some time later tonight I will up
-
Hi Luc, I am glad you answered this will help me to improve the article before it is released. > 1. I don't think the using construct and the IDisposable interface exist or are the same in Java. You're right http://java.sun.com/developer/technicalArticles/javase/finalization/[^] I guess Java programmers will have to create a Close method or have to wait for GC to fire the finalizer. 2. WeakReference class needs to be mentioned, as it alleviates some problems when implementing cache-like data structures. I will have to describe this. The weakreference is useful to let the garbage collector collect some object while still be able to access it if it has not. Weak references are not required in my system. All pointers are effectively weak references apart from the ownership. > One criticism: > I don't believe requiring an owner is wise; most objects don't really have an owner, > i.e. someone creates them, uses them, passes them on, until no one is interested any more. > Who owns the rooms of a house? who owns a book that you borrow? > Passing ownership will soon be required, and then you can make the same mistakes with it, > as you can with (not) freeing a C "object". I need to expand on this obviously. You might well be right. There are a number of potential bugs using my owner: 1 - The programmer creates every objects with the parent being the application. You're right in this scenario nothing will be freed automatically like in C. I will write a few sample in the article where objects will be created with a form as an owner. The owner could also be the current method. I will need to speak about c# stackalloc. > Who owns the rooms of a house? > who owns a book that you borrow? What you give as a parameter is what will determine the lifetime of the object. The term owner perhaps is wrong perhaps it could be called differently. Typically the owner will be your method, or your current object. In some cases it will be the collection you'll put the object in. > Passing ownership will soon be required It is indeed > and then you can make the same mistakes with it, > you can with (not) freeing a C "object". Yes you will have the same C issue here but not some of the worse issues that causes crashes. I will expand this further some time later tonight I will up
OK, I enabled the e-mail widget under this message. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.