Initialization & clean up

Initialization & clean up java

1. Where storage lives

1.1. Registers

This is the fastest storage because it exists in a place different from that of other storage: inside the processor. However, the number of registers is severely limited, so registers are allocated as they are needed. You don‘t have direct control, nor do you see any evidence in your programs that registers even exist (C & C++, on the other hand, allow you to suggest register allocation to the compiler).

1.2. The stack

This lives in the general random-access memory (RAM) area, but has direct support from the processor via its stack pointer. The stack pointer is moved down to create new

memory and moved up to release that memory. This is an extremely fast and efficient way to allocate storage, second only to registers. The Java system must know, while it is creating the program, the exact lifetime of all the items that are stored on the stack. This constraint places limits on the flexibility of your programs, so while some Java storage exists on the stack—in particular, object references—Java objects themselves are not placed on the stack.

1.3. The heap

This is a general-purpose pool of memory (also in the RAM area) where all Java objects live. The nice thing about the heap is that, unlike the stack, the compiler doesn‘t need to know how long that storage must stay on the heap. Thus, there‘s a great deal of flexibility in using storage on the heap. Whenever you need an object, you simply write the code to create it by using new, and the storage is allocated on the heap when that code is executed. Of course there‘s a price you pay for this flexibility: It may take more time to allocate and clean up heap storage than stack storage (if you even could create objects on the stack in Java, as you can in C++).

1.4. Constant storage

Constant values are often placed directly in the program code, which is safe since they can never change. Sometimes constants are cordoned off by themselves so that they can be optionally placed in read-only memory (ROM), in embedded systems.

1.5. Non-RAM storage

If data lives completely outside a program, it can exist while the program is not running, outside the control of the program. The two primary examples of this are streamed objects, in which objects are turned into streams of bytes, generally to be sent to another machine, and persistent objects, in which the objects are placed on disk so they will hold their state even when the program is terminated. The trick with these types of storage is turning the objects into something that can exist on the other medium, and yet can be resurrected into

Initialization & clean up java

a regular RAM based object when necessary. Java provides support for lightweight

persistence, and mechanisms such as JDBC and Hibernate provide more sophisticated support for storing and retrieving object information in databases.

1.6. Static storage

Static means in a fix place (also in the RAM area). Static storage area holds the data that is available all the time when the program is running once it is created. You can specify a field of a object as a static variable with static.

2. Object

The following figure shows the layout of an object on the heap. The parts of the object are explained below the figure.

size + flags

The size + flags slot is 4 bytes on 32 bit architecture and 8 bytes on 64 bit architecture. The main purpose of this slot is to contain the length of the object. As all objects start on an 8 byte boundary, and the size is pisible by 8, the bottom 3 bits are not used for the size; we use them for flags to indicate different states of the object. As the size of objects is limited, the top 2 bits can be used for flags. Note that the mptr, not this slot, is grained on an 8 byte boundary. The flags are as follows:

Bit 1 is the swapped bit that is only used during compaction. Bit 1 is also the

NotYetScanned bit that is only used during mark stack overflow. In addition, Bit 1 is also the multi-pinned bit used to indicate that this object has been pinned multiple times.

During a GC, the multi-pinned bit will be removed and restored to allow other uses of this

Initialization & clean up java

overloaded bit.

Bit 2 is the dosed bit. The dosed bit is set on if the object is referenced from the stack or registers. The object cannot be moved in this GC cycle; we cannot fix up the reference as it may not be a real reference but simply an integer that happens to have the same value as an object on the heap.

Bit 3 is the pinned bit. Pinned objects usually cannot be moved because they are

referenced from outside the heap. Examples include Thread and ClassClass objects. Bit 31 in 32-bit architecture, or bit 63 in 64-bit architecture, is the flat locked contention (flc) bit used by the locking (LK) component.

Bit 32 in 32-bit architecture, or bit 64 in 64-bit architecture, is the hashed bit used to denote an object that has returned its hashed value. This is required, because the hash value is the address of the object and you need to maintain this if you move the object. mptr

The mptr slot is 4 bytes on 32-bit architecture and 8 bytes on 64-bit architecture. The mptr slot, not the size + flags, is grained on an 8 byte boundary. The mptr has one of two functions:

If the mptr slot is not an array, the mptr points to the method block, from which you can get to the class block. The class block tells you which class an object is an instantiation of. The class loader allocates the method block and class block, neither of which are in the heap.

If the mptr slot is an array, the mptr contains the number of array entries in this object. locknflags

This slot is 4 bytes on 32-bit architecture and 8 bytes on 64-bit architecture, although only …… 此处隐藏：15395字，全部文档内容请下载后查看。喜欢就下载吧 ……