This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
JIT is an acronym for Just In Time compiler. Java is an interpreted language. Interpreted language are generally slow beasts by nature. What a JIT does is optimizes calls at runtime using the native platform language to speed things up. The speed of Java applications now rival that of native applications because of JITs. Garbage collection is one of the better aspects of Java. The language it was designed after, C++, has no such facility. The developer had to provide destructors to free resources whenever an object became orphaned. In deep inheritance trees, sometimes destructors would not be called as expected because a developer neglected to create a virtual destructor or override a destructor. This problem led to what is known as memory leaks, the program would eventually be starved for memory because orphaned objects would still be holding on to the memory that was allocated to them. The Java Garbage Collector or GC, keeps up with all object references and when it determines that there are no reachable references to an object it marks that object for garbage collection. When will the object be GCed? When the GC decides it needs the resources. The programmer has little control over it. He can suggest that everything be GCed by calling System.gc(), but in reality it is still up to the GC to actually clean up the orphaned objects as its whim. There is a lot of room for interpretation for how GC should be accomplished by the Java specifications so different JVM vendors will certainly do it in varying ways.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Thulung - Just to add a bit to what Michael said: It won't really matter to you how the GC has been implemented. What *is* important is that you understand how to make sure that objects you're not using any more are eligible to be destroyed by the GC. If your program is creating a lot of large objects, it is good practice to make sure that all of the references to these objects are nulled or reassigned when you are done with the objects. Once all of an object's references have been removed, the GC can destroy that object if it needs to.
Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)