Shared classes initialization requires a number of operations
to succeed. A failure might have many potential causes, and it is
difficult to provide detailed message information following an initialization
failure. Some common reasons for failure are listed here.
If you cannot see why initialization has failed from the command-line output,
look at level 1 trace for more information regarding the cause of
the failure. The SDK and Runtime User Guide for your platform
provides detailed information about operating system limitations.
A brief summary of potential reasons for failure is provided here.
Writing data into the javasharedresources directory
To
initialize any cache, data must be written into a javasharedresources directory,
which is created by the first JVM that needs it.
On Linux®, AIX®, z/OS®,
and i5/OS® this directory is /tmp/javasharedresources. On Windows®, it is C:\Documents
and Settings\<username>\Local Settings\Application
Data\javasharedresources.
On Windows, the memory-mapped file is written
here. On Linux, AIX, z/OS,
and i5/OS this directory is
used only to store small amounts of metadata that identify the semaphore
and shared memory areas.
Problems writing to this directory
are the most likely cause of initialization failure. A default cache
name is created that includes the username to prevent clashes if different
users try to share the same default cache. All shared classes users
must also have permissions to write to javasharedresources.
The user running the first JVM to share classes on a system must have
permission to create the javasharedresources directory.
By
default on Linux, AIX, z/OS,
and i5/OS caches are created
with user-only access. Two users cannot share the same cache unless
the -Xshareclasses:groupAccess command-line option
is used when the cache is created. If user A creates a cache using -Xshareclasses:name=myCache and
user B also tries to run the same command line, a failure occurs.
The failure is because user B does not have permissions to access "myCache". Caches can be removed only by the user who created
them, even if -Xshareclasses:groupAccess is used.
Initializing a persistent cache
Persistent
caches are the default on all platforms except for AIX and z/OS.
The
following operations must succeed to initialize a persistent cache:
- 1) Creating the cache file
- Persistent caches are a regular file created on disk. The main
reasons for failing to create the file are insufficient disk space
and incorrect file permissions.
- 2) Acquiring file locks
- Concurrent access to persistent caches is controlled using operating
system file-locking. File locks cannot be obtained if you try to use
a cache that is located on a remote networked file system. For example,
an NFS or SMB mount. This option is not supported.
- 3) Memory-mapping the file
- The cache file is memory-mapped so that reading and writing to
and from it is a fast operation. You cannot memory-map the cache file
to a remote networked file system, such as an NFS or SMB mount. This
option is not supported. Alternatively, memory-mapping might fail
if there is insufficient system memory.
Initializing a non-persistent cache
Non-persistent caches are the default on AIX and z/OS.
The following operations must succeed to initialize a
non-persistent cache:
- 1) Create a shared memory area
- Possible problems depend on your platform.
- Linux, AIX, z/OS,
and i5/OS
- The SHMMAX operating system
environment variable by default is set low. SHMMAX limits
the size of shared memory segment that can be allocated. If a cache
size greater than SHMMAX is requested, the JVM
attempts to allocate SHMMAX and outputs a message
indicating that SHMMAX should be increased. For
this reason, the default cache size is 16 MB.
- 2) Create a shared semaphore
- Shared semaphores are created in the javasharedresources directory.
You must have write access to this directory.
- 3) Write metadata
- Metadata is written to the javasharedresources directory.
You must have write access to this directory.
If you are experiencing considerable initialization problems, try
a hard reset:
- Run java -Xshareclasses:destroyAll to remove
all known memory areas and semaphores. On a Linux, AIX,
or z/OS system, run this command
as root, or as a user with *ALLOBJ authority on i5/OS.
- Delete the javasharedresources directory
and all of its contents.
- On Linux, AIX, z/OS,
or i5/OS the memory areas
and semaphores created by the JVM might not have been removed using -Xshareclasses:destroyAll.
This problem is addressed the next time you start the JVM. If the
JVM starts and the javasharedresources directory
does not exist, an automated cleanup is triggered. Any remaining shared
memory areas that are shared class caches are removed. Follow one
of these steps to reset the system and force the JVM to re-create
the javasharedresources directory:
- On Linux, AIX, or z/OS,
using root authority, start the JVM with -Xshareclasses.
- On i5/OS, using a user
that has *ALLOBJ authority, start the JVM with -Xshareclasses.