Ebusiness Application Development: Intro Java has greatly simplified Ebusiness application development and deployment through its cross-platform virtual machine, object-oriented semantics, language-intrinsic thread model, and garbage-collection memory management. These features have contributed to greater programmer productivity and more reliable high performance application software.

---

Java has greatly simplified application development and deployment through its cross-platform virtual machine, object-oriented semantics, language-intrinsic thread model, and garbage-collected memory management. These features have contributed to greater programmer productivity and more reliable software.

With distributed computing and Web application support in the form of Remote Method Invocation (RMI), servlets, JavaServer Pages (JSP), and Enterprise JavaBeans (EJB), Java has become a preferred implementation technology for enterprise computing and server-side components of Web applications. As Java becomes adopted increasingly more often for mission-critical tasks and interactive services requiring long up-times and high availability, such as e-commerce applications, it becomes even more important to ensure that your Java applications maintain a high level of performance.

Even though Java accelerates the software development process and increases application stability by relieving programmers from the error-prone task of explicit memory management required by languages such as C and C++, it still requires careful programming to maximize application performance and scalability. Server-side applications tend to be long-lived, allocating and releasing resources many times over their lifetimes. These resources include file descriptors, network and database connections, but primarily memory. Frequent memory allocation and deallocation can adversely affect application performance simply because doing so expends extra CPU cycles, sometimes making a system call to the operating system kernel and incurring a potentially adverse temporal overhead. The temporal costs of memory allocation can be especially detrimental to applications that require fast response times or need to scale to serve large numbers of clients. Java application components, in the form of servlets, JSPs, and EJBs, tend to be long-lived and are especially vulnerable to this problem because Java naturally encourages on-demand object instantiation over more complicated object creation strategies such as object pooling.

Traditional Memory-Related Problems in C/C++

Java memory management is inherently different from that of C/C++ and requires different optimization techniques, even though it is susceptible to some of the same general failings, including memory leaks. C and C++ require a much greater intimacy with memory management on the part of the programmer. Dynamically allocated memory is divided into two regions: the stack and the heap. The stack is a contiguous region of memory that is used to store activation records or function call frames. Every time you call a method or function, a call frame is pushed onto the stack, containing saved registers, function parameters, a return stack pointer, and local variables. This memory allocation is managed for you by the compiler and the operating system. The compiler generates the machine instructions that create the activation records and increment the stack pointer and the operating system handles stack overflows by either dynamically increasing the process stack size or aborting the program with a stack overflow error. Programmers have to make sure they do not create excessively large local objects, else they will consume all of the available stack space.

Large objects are typically allocated on the heap, a global pool of memory available to a program for dynamic object creation. The C malloc and free functions and the C++ new and delete operators allow programmers to explicitly allocate and release heap memory, referencing it with pointers. Where stack-allocated memory is automatically released immediately upon the return of a function, heap memory is not released until the programmer explicitly does so. If a programmer is not careful to release memory after it is no longer needed, the heap space available to a program can gradually decrease in size. This is commonly referred to as a memory leak. Eventually, if a program continues to leak memory, system performance will degrade, sometimes to unusable levels. To minimize this risk, C++ object classes can implement destructors, special methods that are invoked when an object is destroyed. Destructors are used to clean up after an object, usually releasing all memory that was dynamically allocated by the object. Stack-allocated local objects have their destructors automatically invoked at the end of their scope, such as at the end of a method call. The destructors of heap-allocated objects are invoked when their memory is explicitly deallocated with the delete operator. Destructors have to be implemented by the programmer, an often difficult task given the complicated links objects can form to other objects. For example, a hash table may not only contain a dynamically allocated array, but also many linked lists that contain objects with yet more pointers to other objects. The invocation of a single object's destructor can cause a chain of other destructors to be invoked. This is not only potentially expensive in terms of CPU cycles, but also creates extra opportunities for memory leaks to emerge.

To download pdf version of this paper, click on link below