• Handle the appropriate exceptions (checked); do not leave it to the unchecked exceptions – When an exception is thrown, the runtime system will exhaustively search all the methods on the call stack for the appropriate exception handler.  This is expensive and thus we want to minimize the search in the call stack in finding the appropriate exception handler to improve performance which can be achieved by throwing and catching the appropriate exceptions (checked exceptions).  Do not leave exception handling as an after-thought or code-as-you-go during development.
• Do not incorporate exception handling as control flow – As mentioned earlier, exceptions are expensive and should only be used for abnormality (planned and unplanned).  An if-then-else construct will perform better without the exception handling as there is no need to transfer control to locate the appropriate exception handling.   As such, review the codes and remove any throw statements from the coding that are used in an if-then-else construct.
• Avoid and remove the use of Reflection API in the codes – Reflection involves types that are dynamically resolved, which restricts optimization in certain JVMs.  Consequently, reflective operations have slower performance than non-reflective counterparts.  Therefore, unless there is a dire need for reflection to be used in the java program, it is best to leave it out if you need a high performance program.
• Let the system decide the garbage collection – If possible, remove any attempt to call system.gc(). system.gc() triggers a full collection , which includes tracing all live objects in the heap and sweeping and compacting the old generation. This can be a lot of work. In general, it is better to let the system decide when it needs to collect the heap, and whether or not to do a full collection.  Note: system.gc() merely signals (marks) the java program to do garbage collection, but it will not be an immediate garbage collection taking place.
• Reduce memory by avoiding the use of finalizers – An object is in the finalized state if it is still unreachable after running the finalize method, if any, has been run.  The finalized object is then awaiting deallocation and deallocation will not take place until the finalizer is run which is dependent on the VM.  The use of finalizer will extend the lifetime of the finalized object and it can be counter-intuitive when no deallocation takes place and when you intended to have the object being short-lived.   In order to avoid these short-lived objects being extended during the lifetime of the heap memory, it is best to consider the use of finalizers or free the resources explicitly.   (Source: Appendix A, The Truth About Garbage Collection and Java theory and practice: Garbage Collection and Performance)

Both system code and device driver code occupies memory. In addition, the OS allocates data structures in two areas of memory: a pool for non-pageable storage and a pool for pageable storage. Data structures accessed by OS and driver functions when interrupts are disabled must be resident in RAM at the time they are referenced. These data structure are usually allocated from the non-pageable pool so that they reside permanently in RAM. The Pool Nonpages Bytes counter in the Memory object shows the amount of RAM currently allocated that is permanently resident in RAM.

Mainly, though, most system data structure are pageable: they are created in a pageable pool of storage and subject to page replacement like the virtual memory pages of any other process. The Windows OS maintains a working set of active pages in RAM that are subject to the same page replacement policy as ordinary process address spaces. The Cache Bytes counter provides the total number of resident pages in the current system working set. Cache Bytes is the sum of the System Cache Resident Bytes, System Driver Resident Bytes, System Code Resident Bytes, and Pool Paged Resident Bytes counters. The OS’s working set is known as the cache because it also includes resident pages of the Windows file cache, the OS function that typically consumes more RAM than any other.

The system working set is subject to the same local page replacement policy as ordinary process working sets. By default, the system cache has a minimum working set of about 4.8MB and a maximum working set of a little more than 2000 pages, or about 8MB. Just like ordinary processes, when the OS is running at its maximum working set value and it references a page that is not currently resident (causing a page fault), the new page displaces an older page from the system cache and the older page is moved to the Standby List. Just like ordinary processes, when the Balance Set manager thread responsible for page trimming detects that the OS is running at its current working set maximum and at least 4MB of RAM available, it adjusts the system working set upwards 20 pages at a time.

A registry parameter called LargeSystemCache can be set to change the system working set maximum value. When the LargeSystemCache is turned on, the system working set maximum is set to approximately 80% of the total amount of RAM installed.

Turning on the LargeSystemCache setting, which boosts the value of the system’s maximum working set size, favors the system working set over the working sets of other processes. It allows the working set of the system, which includes the Windows file cache, to grow relatively unconstrained in relation to other process working sets and to absorb the bulk of the system’s uninstalled RAM.

(Source: Windows 2000 Performance Guide by Mark Friedman & Odysseas Pentakalos)

In practice, many LRU virtual memory implementations, including the one found in Windows, attempt to maintain some pool of free pages in RAM. This pool of Available Bytes allows the OS to schedule an I/O to the paging file to resolve the page fault immediately. Then, when this pool becomes depleted, a round of page stealing is triggered, which replenishes the pool of free pages before it is completely exhausted. (Windows refer it as page trimming). Windows uses page trimming on a regular basis to maintain its pool of free pages (reported as Available Bytes).

The challenge in Windows is to identify older pages without relying on specific processor hardware support. This is accomplished by trimming pages from process working sets provisionally. After trimming pages aggressively from active processes, Windows adds them to the pool of Available Bytes, but tags them initially as being in a provisional state. They are not immediately removed from RAM. The next time threads from active processes are scheduled to run, they reference the pages are active and these stolen pages are allowed to transition back into the process working set. So-called transition faults or soft page faults are handled quickly, with a minimum overhead. Eventually, what are left behind in the pool of Available Pages are older, unused pages that are good candidates to be replaced.

Trimmed process working set pages are placed initially in the Standby List, where they are allowed to transition fault back into their process working set the next time they are referenced. Transition faults are distinguished from hard page faults, which must be satisfied by reading the paging file disk. Pages in the Standby List that are un-referenced long enough are eventually moved to the Free List. When the System Zero Thread executes, it zeros out the contents of pages on the Free List, which allows them to move to the Zero List. Pages from the Zero List are allocated whenever either a hard page fault occurs or a process references a brand new page (also known as Demand Zero page faults). Together, the size of the Standby List, the Free List, and the Zero List are added together and reported as Available Bytes.

The page trimming procedure is threshold-driven. Page trimming is invoked when one or more of the List structures that make up the pool of Available Bytes is depleted. In addition, Windows schedules writes to the paging file when the number of changed pages exceeds a threshold value. Modified pages are written in bulk to disk by Modified Page Writer threads, again based on the threshold values being exceeded.

Measurement Support

The Transition Faults/sec counter in the Memory object reports the rate at which soft page faults occur. Similarly, Demand Zero Faults/sec reports the rate at which new pages are being created. Pages Output/sec shows the rate at which changed pages had been copied to disk. By implication, since real memory is a closed system:

Pages trimmed/sec = Transition Faults + Demand Zero Faults + Hard page faults

Plus any change in the size of the Available Bytes buffer from one interval to the next. The individual sizes of the Standby, Free, and Zero lists are not reported. Nor does Windows report the rate at which the Balance Set Manager’s page trimming routine runs, nominally at least once per second.

The Pages Read/sec counter corresponds to the rate of hard page faults requiring the OS to retrieve a page from disk. The fact that Pages Input/sec is usually larger than Pages Read/sec reflects the use of anticipatory paging. Pages Input/sec is the actual number of pages retrieved from disk. Calculating:

Pages per page fault = Pages Input/sec / Pages Read/sec

Reports the average number of pages retrieved per page fault. Similarly, the Pages written/sec counter shows the number of page write operations that were initiated, and Pages output/sec counts the number of physical 4K pages actually written.

When the average number of pages read or written to disk is consistently above two pages per page fault or page write operation, and more than 10 – 20% of all I/Os to the disk are the result of paging operations, it is probably time to add another paging file , if possible. Adding a second paging file spreads the paging I/O load across another physical disk and usually improves page fault resolution time substantially.

Windows supplies one other important measurement of overall paging activity, namely Page Faults/sec. Unfortunately, interpreting how the Page Faults/sec counter relates to the other paging activity counters is problematic. Page Faults/sec includes both Transition (soft) Faults/sec and hard page faults (Pages Read/sec). It evidently also includes the number of Cache Faults/sec due to the normal diversion of application I/O to the paging subsystem. There is strong evidence that it also includes the number of Demand Zero Faults/sec.

Page Faults/sec = Cache Faults/sec + Demand Zero Faults/sec + Pages Read/sec + Transition Faults/sec

(Source: Windows 2000 Performance Guide by Mark Friedman & Odysseas Pentakalos)

When you launch Task Manager, on the Performance Tab, the MEM Usage and Memory Usage History Graphs refer to virtual memory Committed Bytes. The value corresponds to the Commit Charge (K) Total field in the lower-left quadrant. The Task Manager Commit Charge field reports on virtual memory allocations in 1024 kilobytes (KB) segments; the corresponding Committed Bytes Limit is also shown. The Memory Usage History graph charts Committed Bytes against the Commit Limit, which servers as the maximum value for the Y-axis.
In the upper-right text quadrant (immediately below the Memory Usage History timeline), the Task Manager shows Total system memory (the amount of installed RAM), Available, and System Cache, all denominated in 1000 bytes. The Task Manager Available field corresponds exactly to the System Monitor Available Kbytes counter, by the way.

As you open new applications on your desktop, watch as virtual memory Committed Bytes increases while Available Bytes decreases in tandem. As a general rule of thumb, a 5 – 10% cushion of Available Bytes is normally ample.

If you are able to start enough application programs, you will eventually observe that the number of Committed Bytes begins to exceed the amount of physical RAM installed. This is the first indication that real memory might be filling up. As long as Committed Bytes is less than the amount of RAM installed, every virtual memory page requested by application process can fit in RAM. That means the amount of RAM installed is sufficient for this workload. However, just because Committed Bytes is greater than the amount of RAM installed dos not mean RAM is completely allocated. Some applications committed pages that have not been referenced in a long time may not be currently resident in real memory. Idle pages are subject to being paged out of the system, so RAM may still not be completely allocated.

Windows continues to permit applications to allocate more virtual memory up to the Committed Bytes Limit. If your applications continue to add more Committed Bytes to the system, at some point all those active virtual memory pages will not fit easily into physical RAM and you will start to notice an impact on system performance. At this point of time, when you click on an application that you have not accessed in a while, you are likely to hear the hard disk grinding away. Windows is performing paging I/O to the disk, taking older pages in memory and writing them to the paging file to make room for current pages that t must read back into memory from the paging file disk. As you continue to open new applications and drive Committed Bytes higher, the slowdown in system performance will eventually become acute, which eventually might leads to trashing.

When the number of virtual memory Committed Bytes starts to exceed the amount of physical RAM installed, you can probably also observe that the number of Available Bytes begins to stabilize at approximately 4MB. Windows attempts to maintain a 4MB cushion of Available Bytes in order to service application requests for a new page quickly. If the working sets of active processes exceed the size of physical memory, there is contention for real memory. In Windows, you can often observe signs of this contention when the system’s pool of Available Bytes reaches about 4MB. At approximately 4MB of available RAM, Windows crosses a threshold where behavior of its virtual memory management policy changes. If Windows has difficulty maintaining a 4MB pool of available RAM and the demand for virtual memory continues to increase, you will likely observe telltale signs of trashing.

(Source: Windows 2000 Performance Guide by Mark Friedman & Odysseas Pentakalos)

When the systems reaches the 90% threshold, not only are there few available virtual memory slots, what slots are available maybe very scattered, preventing applications from allocating large blocks of virtual storage. When the system is approaching the Commit Limit, applications may begin to fail because they cannot allocate virtual memory. For instance, the system application responsible for sending the warning message to the console and to the event log that the paging file is 90% full sometimes fails because it cannot allocate virtual memory, so you might not even receive notification that the event has occurred. In short, by the time the 90% paging file allocation threshold is reached, it may already be too late to take corrective action.

A more proactive approach uses continuous performance monitoring to generate an alert when % Committed Bytes exceeds, say, a 70% threshold value. If you are operating a system above this level of virtual memory utilization consistently, it is time to explore longer-term remedial measure that might involve adding more physical memory, defining additional paging file space, or both. Computers systematically exceeding 70% – 80% Committed Bytes may suffer from serious performance degradation due to excessive demand paging activity anyway.

(Source: Windows 2000 Performance Guide by Mark Friedman & Odysseas Pentakalos)

If the supply of real memory is ample, executing programs seldom encounter page faults that delay their execution, and the OS has no difficulty maintaining a healthy supply of free pages.If the system is short on real memory (relative to the memory required to back concurrently referenced pages with actual physical memory pages), a high rate of page fault may occur, slowing the performance of executing programs considerably. Obviously, the OS may not be able to maintain an adequate pool of available real memory when there is not enough real memory to go around.

You want to avoid three types of performance problems that can occur when there is too little real memory:
Too many page faults: Having too many page faults leads to excessive program execution delays during page fault resolution. This is the most straightforward performance problem associated with virtual memory addressing.

Disk contention: Virtual memory systems that are subject to a high page fault rate may also encounter disk performance problems because of the extra disk I/O workload generated to resole page faults. In systems where the paging file (or files) is located on the same disk (or disks) as application data files, I/O to the paging file can limit the ability of applications to access their own data files. A possible secondary effect of disk contention is elongation of page fault resolution time, further delaying the programs affected when page faults do occur.

Competition for memory: Because real memory is allocated to executing programs on demand, there is another potential pitfall. In virtual memory systems, programs resident in memory compete for access to available physical memory. The inevitable result of competition when memory is scarce is that the memory access pattern of one program can unduly influence other running programs.

A severe shortage of real memory can seriously impact performance. Moving pages back and forth between disk and memory consumes both processing and disk capacity. A system forced to use too many CPU and disk resources on virtual memory management tasks and too few on the application workload is said to be thrashing.

Inevitably, the solution to a paging problem is to install more real memory capacity. Alternatively (and less definitely), it may help to improve page fault resolution time by focusing on disk I/O performance. This typically involves some combination of the following.

• Defining additional paging files across multiple (physical) disks,
• Reducing disk contention by removing other heavily accessed files from the paging file physical disks, or
• Upgrading to faster disks.

(Source: Windows 2000 Performance Guide by Mark Friedman & Odysseas Pentakalos)

(Source:Windows 2000 Performance Guide by Mark Friedman & Odysseas Pentakalos)

When an executable program’s image file is first loaded into memory, the logical memory address range of the application is divided into fixed-size chunks called pages. These logical pages are them mapped to similar-sized physical pages that are resident in real memory.

This mapping is dynamic in that frequently referenced logical addresses tend to reside in physical memory (also know s RAM, real memory, or main memory), while infrequently referenced pages are relegated to paging files on secondary disk storage. The active subset of virtual memory pages associated with a single process’s address space currently resident in RAM is known as the process’s working set, because they are the active pages referenced by the programs as it executes.

Virtual addressing is designed to be transparent to application programs, allowing them to be written without regard to specific real memory limitations of this or that computer. Virtual addressing even makes it possible for an executing program to reference an address space that is larger than the amount of physical memory installed on a particular computer. Virtual addressing allows a programmer to exploit what looks like a virtually infinite-sized computer memory where each individual process can address up to 4 GB of virtual addresses. As of the above, performance issues still exists when the OS attempts to reference more memory locations than can actually fit inside real memory.

Virtual memory system works well because executing programs seldom require all the associated code and data areas they allocate to be resident in physical memory concurrently in order to run. With virtual memory, only the active pages associated with a program’s current working set remain resident in real memory. On the other hand, virtual memory systems can run very poorly when the working sets of active processes greatly exceed the amount of physical RAM that the computer contains. It is important to understand the logical and physical memory usage to diagnose performance problems arising from real memory being over-committed.

(Source: Windows 2000 Performance Guide by Mark Friedman & Odysseas Pentakalos)

Paging affects system performance in many ways. One, is that if a process moved some some pages to disk and the process becomes runnable, the OS has to retrieve the pages from the disk before that process can be run which results to delays in performance. In addition, both CPU and the disk I/O spend time doing the paging, reducing available processing power and increasing the load on the disks. This cascading effect involving both the CPU and I/O can degrade the performance of the whole system in such a way that it maybe difficult to even recognize that paging is the problem. The extreme version of too much paging is thrashing, in which the system is spending too much time moving pages around that it fails to perform any other significant work. (The next step is likely to be a system crash).

A little paging of the system does not affect the performance enough to cause concern. In fact, some paging can be considered good which indicates that the system’s memory resources are fully utilized. But at the point where paging becomes a significant overhead, the system is overloaded. To monitor paging activities is easy. On UNIX, the utilities vmstat and iostat provide details as to the level of paging, disk activity and memory levels. On Windows, the performance monitor has categories to show these details, such as Pages/sec, Page faults/sec and % Page files usage.

If there is more paging than optimal, the system’s RAM is insufficient or processes are too big. To improve this situation, you need to reduce the memory being used by (a) reducing the number of processes or (b) the memory utilization of some processes. Alternatively, you (c) can add RAM.  If the problem is caused by a combination of your application and others, you can partially address the situation by using process priorities. By issuing priorities to the processes, you need to be aware that using this option reduces the amount of RAM available to all other processes, which can make overall system performance worse. Therefore measure the trade-offs before deciding the resolution.

(Source: “Java Performance Tuning”)

The telltale sign of a memory leak is that Committed Bytes at the system level and/or Virtual Bytes at the process level are continuously increasing. Eventually, a program with a memory leak exhausts the system’s supply of virtual memory, which can cause other running programs and even system code to fail as the system runs up against the virtual memory Committed Bytes limit. Depending on the rate at which the defective program leaks memory and the amount of excess virtual memory available, it can be a long time before any dire effects are evident.

A program that is leaking memory by allocating and then failing to free some private virtual memory areas is relatively easy spot because the process Virtual Bytes counter is continuously increasing. It is often harder to detect programs that allocate shared memory from the system’s Pageable Pool and fail to release that. Because virtual memory allocated in the shared memory region of the Pageable Pool is not associated with any specific process, finding the offending program can be difficult. Often, it is necessary to use the process elimination to find the offender.

(Source: Windows 2000 Performance Guide, Mark Friedman & Odysseas Pentakalos)