With Java shared cache support, Java stores classes and JIT information in shared memory, so it can be reused by other Java applications, or it the application is restarted.
Some other shared classes blog posts
- A good, comprehensive introduction
- Introduction to Java Shared classes on z/OS
- Saving a copy of the Java Shared classes to disk
- Restoring a copy of the Java Shared classes cache from disk.
- What’s happening with my Java shared classes?
You can use the Java command snapshotCache to save the shared buffer to disk, and restoreSnapshot to restore from disk to recreate the shared memory.
For my Zowe startup I use Java start-up option
-Xshareclasses:verboseIO,verbose,name=zoweGW,cacheDirPerm=0777,cacheDir=/u/tmp/zowec/
Before you start you need to consider
- Sharing the shared classes cache
- Which directory to use
- What name to use
- How big
- Processes to save the cache to disk
- Read only?
Sharing the shared classes cache
Java uses a semaphore when updating the shared classes cache. I believe that multiple Java instances can share the cache, so products which have multiple address spaces can share the same cache if they are using the same level of Java.
I believe you could use one shared classes directory for all your Java applications, Liberty, z/OSMF, zOS Connect, Zowe etc. I haven’t found any documentation to say you cannot share it, but the application’s userid needs access to the cache, and so may need the same userid, or be in the correct group to be able to access the cache, and ipc memory and semaphores. The Zowe address spaces all use the same userid, so all have access to the cache.
To further complicate it…
You can run more than one JVM within a CICS address space, they can all use the same cache.
To be able to destroy and recreate a cache (for example to make it larger ), the cache cannot be in use. For availability you may want multiple caches so you do not need to shutdown all CICS regions to be able to recreate it. As all Zowe address spaces start and stop together, they can use a shared classes cache.
Which directory to use?
If you do not specify a cachDir, it defaults to /tmp. This is OK – but some on some z/OS systems, the /tmp directory is emptied on a regular basis. This means your cache is deleted, and it needs to be recreated next time your application starts.
For Zowe I used /u/tmp/zowec.
What name to use?
If you do not specify a name it takes the userid of the application, as part of the file name.
Within my cacheDir, it creates a directory javasharedresources. Within this directory I have files
- C290M21F1A64S_zoweGW_G43L00 with size 83886080 (84MB) this is the hardened copy of the cache
- C290M21F1A64_semaphore_zoweGW_G43L00 with size 32
- C290M21F1A64_memory_zoweGW_G43L00 with size 40
Where the …M21F… is the level ofJava.
When I use the printStats command, it gives the cache size as 84MB.
How big?
I specified
-Xscmx80m
-Xscmaxaot180m
-Xscmaxjitdata30m
Once you have specified the size, you cannot change it unless you delete and recreate the cache, so you need to get it right before you start. Make it too large, rather than too small. Restoring it from a snapshot will use the size when the snapshot was taken.
Processes to save the cache to disk.
As part of your application shutdown you could snapshot the cache to a file. See here (tba).
Processes to save the cache to disk.
You might want to restore the cache from disk as part of your IPL processing, or as part of application start up. If the cache already exists it is not overwritten. It takes a few seconds to snapshot or restore. See here(tba).
Clean up the shared classes
If you delete the ipc shared memory, and the ipc semaphore before you start your Java application, will rebuild the shared classes – though this will take longer as all of the classes need to be read and processed.
Read only
If Java detects that the shared classes cache is out of date, it will updates the shared classes cache.
Once you created and populated a shared classes cache, you can specify readOnly, to prevent updates to it
ColinPaice 