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. The only exception is for non-persistent caches on Linux®, AIX®, z/OS®, and i5/OS®. These caches can be removed only by the user that created the cache. Caches can only be removed if they are not in use.
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.
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. They can then only be identified and removed using the ipcs and ipcrm commands on Linux, AIX, z/OS, and i5/OS.
The reset suboption can also be used to cause a JVM to refresh an existing class cache when it starts. The cache is removed and 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.