Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Thinking in Java
Prev Contents / Index Next

Where storage lives

It’s useful to visualize some aspects of how things are laid out while the program is running—in particular how memory is arranged. There are six different places to store data:

  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 by the compiler according to its needs. You don’t have direct control, nor do you see any evidence in your programs that registers even exist.
  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 compiler must know, while it is creating the program, the exact size and lifetime of all the data that is stored on the stack, because it must generate the code to move the stack pointer up and down. 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. 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 much storage it needs to allocate from the heap or 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 to create 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 takes more time to allocate heap storage than it does to allocate stack storage (if you even could create objects on the stack in Java, as you can in C++).
  3. Static storage. “Static” is used here in the sense of “in a fixed location” (although it’s also in RAM). Static storage contains data that is available for the entire time a program is running. You can use the static keyword to specify that a particular element of an object is static, but Java objects themselves are never placed in static storage.
  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.
  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 a regular RAM-based object when necessary. Java provides support for lightweight persistence, and future versions of Java might provide more complete solutions for persistence. Special case: primitive types

    One group of types, which you’ll use quite often in your programming, gets special treatment. You can think of these as “primitive” types. The reason for the special treatment is that to create an object with new—especially a small, simple variable—isn’t very efficient, because new places objects on the heap. For these types Java falls back on the approach taken by C and C++. That is, instead of creating the variable by using new, an “automatic” variable is created that is not a reference. The variable holds the value, and it’s placed on the stack, so it’s much more efficient.

    Java determines the size of each primitive type. These sizes don’t change from one machine architecture to another as they do in most languages. This size invariance is one reason Java programs are portable.

    Primitive type

    Size

    Minimum

    Maximum

    Wrapper type

    boolean




    Boolean

    char

    16-bit

    Unicode 0

    Unicode 216- 1

    Character

    byte

    8-bit

    -128

    +127

    Byte

    short

    16-bit

    -215

    +215—1

    Short

    int

    32-bit

    -231

    +231—1

    Integer

    long

    64-bit

    -263

    +263—1

    Long

    float

    32-bit

    IEEE754

    IEEE754

    Float

    double

    64-bit

    IEEE754

    IEEE754

    Double

    void




    Void

    All numeric types are signed, so don’t look for unsigned types.

    The size of the boolean type is not explicitly specified; it is only defined to be able to take the literal values true or false.

    The “wrapper” classes for the primitive data types allow you to make a nonprimitive object on the heap to represent that primitive type. For example:

    char c = 'x';
    Character C = new Character(c);


    Or you could also use:

    Character C = new Character('x');


    The reasons for doing this will be shown in a later chapter.

    High-precision numbers

    Java includes two classes for performing high-precision arithmetic: BigInteger and BigDecimal. Although these approximately fit into the same category as the “wrapper” classes, neither one has a primitive analogue.

    Both classes have methods that provide analogues for the operations that you perform on primitive types. That is, you can do anything with a BigInteger or BigDecimal that you can with an int or float, it’s just that you must use method calls instead of operators. Also, since there’s more involved, the operations will be slower. You’re exchanging speed for accuracy.

    BigInteger supports arbitrary-precision integers. This means that you can accurately represent integral values of any size without losing any information during operations.

    BigDecimal is for arbitrary-precision fixed-point numbers; you can use these for accurate monetary calculations, for example.

    Consult the JDK documentation for details about the constructors and methods you can call for these two classes.
    Thinking in Java
    Prev Contents / Index Next


 
 
   Reproduced courtesy of Bruce Eckel, MindView, Inc. Design by Interspire