IBM User Guide for Java V7 on Windows > Troubleshooting and support > Using diagnostic tools > Shared classes diagnostic data > Deploying shared classes

Cache housekeeping

Unused caches on a system waste resources that might be used by another application. Ensuring that caches are sensibly managed is important.

The JVM offers a number of features to assist in cache housekeeping. To understand these features, it is important to explain the differences in behavior between persistent and non-persistent caches.

Persistent caches are written to disk and remain there until explicitly removed. Persistent caches are not removed when the operating system is restarted. Because persistent caches do not exist in shared memory, the only penalty of not removing stale caches is that they take up disk space.

Non-persistent caches exist in shared memory and retain system resources that might be used by other applications. However, non-persistent caches are automatically purged when the operating system is restarted, so housekeeping is only an issue between operating system restarts.

To perform housekeeping functions successfully, whether automatically or explicitly, you must have the correct operating system permissions. In general, if a user has the permissions to open a cache with read-write access, they also have the permissions to remove it. These caches can be removed only by the user that created the cache. Caches can only be removed if they are not in use.

The JVM provides a number of housekeeping utilities, which are all suboptions to the -Xshareclasses command-line option. Each suboption performs the explicit action requested. The suboption might also perform other automated housekeeping activities. Each suboption works in the context of a specific cacheDir.

destroy

This suboption removes all the generations of a named cache. The term "generation" means all caches created by earlier or later service releases or versions of the JVM.

destroyAll

This suboption removes all caches in the specified cacheDir.

expire=<time in minutes>

This suboption looks for caches which have not been connected to for the <time in minutes> specified. If any caches are found which have not been connected to in that specified time, they are removed.

expire=0

This suboption is the same as destroyAll.

expire=10000

This suboption removes all caches which have not been used for approximately one week.

There is also a certain amount of automatic housekeeping which is done by the JVM. Most of this automatic housekeeping is driven by the cache utilities. destroyAll and expire attempt to remove all persistent and non-persistent caches of all JVM levels and service releases in a given cacheDir. destroy only works on a specific cache of a specific name and type.

Cases where the JVM attempts automatic housekeeping when not requested by the user include:

• When a JVM connects to a cache, and determines that the cache is corrupt or was created by a different service release. The JVM attempts to remove and re-create the cache.

With persistent caches, it is safe to delete the cache files manually from the file system. Each persistent cache has only one system object: the cache file.

It is not safe to delete cache files manually for non-persistent caches. The reason is that each non-persistent cache has four system objects: A shared memory area, a shared semaphore, and two control files to identify the memory and semaphores to the JVM. Deleting the control files causes the memory and semaphores to be leaked.

The reset suboption can also be used to cause a JVM to refresh an existing class cache when it starts. All generations of the named cache are removed and the current generation is re-created if it is not already in use. The option -Xshareclasses:reset can be added anywhere to the command line. The option does not override any other Xshareclasses command-line options. This constraint means that -Xshareclasses:reset can be added to the IBM_JAVA_OPTIONS environment variable, or any of the other means of passing command-line options to the JVM.

Parent: Deploying shared classes

Error 404 - Not Found

The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.