The Heap Threads Basic Terminology

Throwable.printStackTrace ; to the bank examples client application. This stack is important because it lets us attach information to the programs flow of execution. In particular, it is useful to think of the stack as containing the following information: The arguments to the method being called Primitive arguments are passed by value, and objects are passed by reference. This means that if you pass an integer into a method, and the method changes the value, the change isnt visible to the calling method. However, if you pass an object to a method, any changes to the object are visible to the calling method. Locally scoped variables with primitive types. When an int or float is declared within a method, that variable is accessible only while that particular method is on top of the stack. Furthermore, locally scoped variables are accessible by only one particular stack frame. If a method appears twice in the calling stack, there are two distinct and independent sets of local variables. Synchronization information. I havent explained this yet. And, technically speaking, this information isnt stored in the stack frames. But, nonetheless, it is often useful to associate synchronization information with the method with which it is acquired and eventually released.

11.2.2 The Heap

We explicitly limited the stack information to locally scoped primitive variables. One reason for this is because objects in Java never have local scope. That is, the Java VM stores all the objects for a single application in a single data structure, often referred to as the applications heap. Since all stack frames have access to the application heap, storing objects in a single heap makes it easier to return objects from method calls. In other languages, care has to be taken as to whether an object was allocated on the stack or on the heap. Objects allocated on the stack have local scope; they are part of the stack frame and will be thrown away when the stack frame is removed from the calling stack. That is, limiting the scope makes memory management easier. Objects allocated on the heap, on the other hand, can be referenced from any stack frame and hence can be used as return values from method calls. But figuring out when the object is no longer useful and can be destroyed is much more difficult. Java solves this problem by making garbage collection, which is the automatic cleanup of the heap to remove objects that are no longer referenced, part of the basic language specification.

11.2.3 Threads

A thread is basically two things, plus some glue: • A calling stack • A thread-specific cache that contains local copies of some of the heap objects that I will sometimes, in a flagrant abuse of terminology, call the local heap. The idea is simple: if you want a program to perform more than one operation at a time, you ought to keep the information for each thing the program does. A thread is simply the name for the data structure that does this. There is a slight problem here. Namely, in a single-processor machine, how can a program be capable of doing more than one thing at a time? The answer is that either the JVM via so-called green threads or the operating system via native threads is responsible for making sure that each thread is occasionally active. That is, either the JVM or the OS manages the threads and makes sure that each thread can use a percentage of the processors time. The process of doing this is often called time-slicing or context-switching;the piece of code that does it is often called the thread-scheduler. Time-slicing is a rather expensive process. The price you pay for doing two things at once is the cost of switching between the associated threads and, occasionally, of copying the local caches to the heap. All of this terminology is conveniently, if slightly inaccurately, summed up in the JVMs internal structure illustrated in Figur e 11- 4 . Figure 11-4. Internal structure of the JVM

11.2.4 Mutexes