heaps in Java and garbage collection
Kevin Peterson
Ranch Hand
Posts: 37
posted 12 years ago
Hello, I am trying to learn some C++ right now, I am a computer science student at a college that bases thier curriculum around Java. I was trying to make some sense of heaps in C++, are there heaps in java but we dont need to do much with them because the garbage collector acts as the deconstructor()?
Thanks, Kevin
Thanks, Kevin
Jeremy French
Greenhorn
Posts: 13
Jeremy French
Greenhorn
Posts: 13
posted 12 years ago
Ok. Maybe I can expound a little further. But essentially, you hit the nail on the head. Java has a heap, and being aware of it and how it works makes you a better programmer, but you can probably get by in ignorance. When an object (The only things stored on the heap) has no more references to it, it becomes available for GC. In terms of memory, the object still exists, but your code can't get to it. The Garbage collector then waits for either spare processor cycles or an imminent need for memory to deconstruct qualifying objects. As such, we don't need to worry about deconstructors unless there's some other aspect of the object that needs to be left in a particular state (such as db values).
There are 10 kinds of people in the world. Those that read binary and those that don't.
Kevin Peterson
Ranch Hand
Posts: 37
posted 12 years ago
yea so does garbage collector actully slow java down since it determines when to destroy your object. because in C++ being able to/required to destroy objects can be done exactily when you want it to which is generally right when the object is derefrenced as opposed to when more processing speed is needed.
By destroying the object right after it is derefreneced as opposed to when more memory is needed would allow for current live objects to run quicker and more efficently?
-Kevin
By destroying the object right after it is derefreneced as opposed to when more memory is needed would allow for current live objects to run quicker and more efficently?
-Kevin
Kannan BLR
Greenhorn
Posts: 10
M Beck
Ranch Hand
Posts: 323
posted 12 years ago
the subject of garbage collectors and their impact on runtime speed has been debated back and forth for literally decades. there's no clear resolution either one way or the other, but garbage collectors do tend to get better as time goes on.
in theory, collecting your garbage manually the C++ way might make your code run faster. but be aware of why this is: it's because you're essentially just writing your own garbage collector that runs when you think it needs to run, and as long as you think it needs to run. in return for this fine-grained control over your home-made GC, you take on the burden of making sure it runs enough: that all your garbage really does, eventually, get collected. if you fail, you leak memory.
on top of that, the strategy you advocate — GC'ing every object as soon as it's destroyed — isn't necessarily the best for making your program run fast. what if there's some urgent job your program would be better off seeing to instead of collecting that garbage? might it not be smarter to put off memory management chores until nothing else interesting is happening? how do you reliably do that in a language like C++?
some famous programmers (Jamie Zawinski comes to mind) have argued that a good garbage collector is a net win even if it slows you down, because you won't leak memory and you won't have to worry about manually collecting garbage, so you'll have fewer bugs to fix and more time to think about writing your actual program instead of managing memory — and programmer time is more expensive than computer time. i myself tend to fall in this camp.
other people think down the lines you outlined, and insist that if they get enough control over exactly what their code does and exactly when it happens, they can always write better code. this may be true, but if so, why aren't they writing machine code...?
in theory, collecting your garbage manually the C++ way might make your code run faster. but be aware of why this is: it's because you're essentially just writing your own garbage collector that runs when you think it needs to run, and as long as you think it needs to run. in return for this fine-grained control over your home-made GC, you take on the burden of making sure it runs enough: that all your garbage really does, eventually, get collected. if you fail, you leak memory.
on top of that, the strategy you advocate — GC'ing every object as soon as it's destroyed — isn't necessarily the best for making your program run fast. what if there's some urgent job your program would be better off seeing to instead of collecting that garbage? might it not be smarter to put off memory management chores until nothing else interesting is happening? how do you reliably do that in a language like C++?
some famous programmers (Jamie Zawinski comes to mind) have argued that a good garbage collector is a net win even if it slows you down, because you won't leak memory and you won't have to worry about manually collecting garbage, so you'll have fewer bugs to fix and more time to think about writing your actual program instead of managing memory — and programmer time is more expensive than computer time. i myself tend to fall in this camp.
other people think down the lines you outlined, and insist that if they get enough control over exactly what their code does and exactly when it happens, they can always write better code. this may be true, but if so, why aren't they writing machine code...?
Kevin Peterson
Ranch Hand
Posts: 37
posted 12 years ago
Thank you , I understand what you are saying and I belive GC in java is a good help but until I see game performance like Doom 3 ect.. that are being pushed onto shelves that are coded in pure java I will then feel dumb for under estimating javas speed. And please note I understand that theres articles saying how Java is just as fast as C++ and I belive that, its just that I m not seeing any results in the gaming sense.
-Kevin
-Kevin
|