The following list describes possible cache problems.
- Cache is full
- A full cache is not a problem; it just means that you have reached
the limit of data that you can share. Nothing can be added or removed
from that cache and so, if it contains a lot of out-of-date classes
or classes that are not being used, you must destroy the cache and
create a new one.
- Cache is corrupt
- In the unlikely event that a cache is corrupt, no classes can
be added or read from the cache and a message is output to stderr.
If the JVM detects that it is attaching to a corrupted cache, it will
attempt to destroy the cache automatically. If the JVM cannot re-create
the cache, it will continue to start only if -Xshareclasses:nonfatal is
specified, otherwise it will exit. If a cache is corrupted during
normal operation, all JVMs output the message and are forced to load
all subsequent classes locally (not into the cache). The cache is
designed to be resistant to crashes, so, if a JVM crash occurs during
a cache update, the crash should not cause data to be corrupted.
- Could not create the Java virtual machine message
from utilities
- This message does not mean that a failure has occurred. Because
the cache utilities currently use the JVM launcher and they do not
start a JVM, this message is always produced by the launcher after
a utility has run. Because the JNI return code from the JVM indicates
that a JVM did not start, it is an unavoidable message.
- -Xscmx is not setting the cache size
- You can set the cache size only when the cache is created because
the size is fixed. Therefore, -Xscmx is ignored unless a new
cache is being created. It does not imply that the size of an existing
cache can be changed using the parameter.