Memory management across languages
- Where to go from here
Viewers: in countries Watching now:
Finally, the course compares how code is written in several different languages, the libraries and frameworks that have grown around them, and the reasons to choose each one.
- Writing source code
- Understanding compiled and interpreted languages
- Requesting input
- Working with numbers, characters, strings, and operators
- Writing conditional code
- Making the code modular
- Writing loops
- Finding patterns in strings
- Working with arrays and collections
- Adopting a programming style
- Reading and writing to various locations
- Managing memory usage
- Learning about other languages
Memory management across languages
We have to grab hold of a piece of RAM and say, "I am going to use this." Then we can create our object and we can point it to that area of memory. We say, "That's what you are using. That's where your data is being stored." We use that reference what's called a pointer to that object and just use the object, call its methods, access its properties. But at some point what we are going to have to do is realize that we are not using it anymore. We don't need that memory, so we free the memory. It doesn't sound too hard, but when you start passing around these objects, you start calling functions, you start having a long lived program, this can get quite difficult.
A very common mistake is this. We allocate some memory, we then create an object, we start using that object, and then nothing. We actually don't need the object anymore, but we forgot to free the memory, or we thought we were freeing it, but we didn't free it probably. Well, that gives us a memory leak. Not a problem if you only do this once, but if you have a long-lived program that creates thousands of objects, as our program runs, it's going to get slower and slower and take up more and more memory, and at some point may even crash because of it.
But the memory leak isn't the only problem we can have. If, for example, we go back to our first object where we've already freed up that memory, well there might still be a variable that's actually pointing to that area of memory. It's what's called a pointer. And if we try and use that variable because we think the object still exists but it doesn't, we have what's called a dangling pointer, and that can actually cause our program to crash. And because memory management is difficult code to write, what's happened is as more high-level languages have evolved, there's been different methods for dealing with it.
If you remember early on in the course, we talked about the idea of low-level to high-level languages. The languages like assembly language and C were actually quite close to the machine code. You had to know a lot about how the machine operated, whereas things like Java, C#, and VB.NET were further away, you didn't have to think about that as much. Well, memory management is one of those areas. If you're working with assembly language, and C, you have to do a lot of manual work to allocate and free areas of memory that you're using.
As you start to get into the more modern high-level languages, there are techniques for dealing with it. Objective-C and C++ can choose to use something called reference counting. This is preferable to manual memory management and it allows us to keep a counter of who is using the object, but rather than manually free the memory, we just allow the system to free it up when it realizes that counter has reached 0. If we move into languages like Java, C#, and VB.NET, there is a memory management technique called garbage collection.
Rather than keep track of individual objects, what happens is the system itself keeps track of how much memory your application is using. And at certain times in your program's lifetime, what it's going to do is scan through all your objects and figure out which ones are still relevant, which ones are still being used. So it might take a sweep through a thousand objects, clear up 500 of them, and leave 500 of them around. It's called garbage collection because it bashes this up. It doesn't happen all the time.
In fact, you can't even guarantee when it will happen. When you're dealing with these languages, sometimes as a programmer, you can kind of suggest to the garbage collector that it might be a good time to go and clear up areas of memory, but you don't have to work on the individual level of the individual objects. And further up, when you get into more scripting languages, it's really fully automatic. You have either no or next to no control over when memory will be reclaimed. Now, you might think well, the automatic one sound great. The issue is of course that the more automatic it is, usually the slower it is, the less efficient it is.
Because while writing manual memory management code is tedious, it's difficult to do, if you can do it right, it leads to the most efficient use of memory, and if that's your goal, then you might be looking at languages that allow you to do manual memory management. However, for productivity, and particularly because we're in a world where we really don't have to worry about memory quite as much as we used to going back a couple of decades, you will find that the higher level languages using things like garbage collection, they usually win for being able to create code and create programs faster.
Find answers to the most frequently asked questions about Foundations of Programming: Fundamentals .
Here are the FAQs that matched your search "" :
- Q: Using TextEdit with Mac OS 10.9 Mavericks?
Sorry, there are no matches for your search "" —to search again, type in another word or phrase and click search.