[IBM JVM] MULTIPLE SIMULTANEOUS JVM STARTUPS MAY CAUSE HANGS IN SEMOP

PK87235: MULTIPLE SIMULTANEOUS JVM STARTUPS MAY CAUSE HANGS IN SEMOP

APAR status

• Closed as program error.

Error description

• A race condition exists where starting several instances of the
  Java Virtual Machine simultaneously can result in a hang of some
  or all of the intances.
  
  This problem only manifests itself when the several
  simultaneous JVMs were created with Shared Classes enabled, and
  where all of the JVMs shared the same Shared Class Cache.
  
  The stack at hang will be:
  semop
  j9shsem_wait
  SH_OSCache::startup(const char*,const char*,long
  SH_CompositeCache::startup(J9VMThread*,char*,uns
  SH_CacheMap::startup(J9VMThread*,const char*,con
  j9shr_init
  ....
  
  
  After this issue has occurred, it is very likely that the state
  of shared class caches on the system will be unstable. Later
  servers to start (even when done individually) will also hang if
  the in-error shared class control files still exist.
  

Local fix

• Deactivate Shared Classes by either removing the -Xshareclasses
  parameter to the JVM, or by passing:
  -Xshareclasses:none
  
  It is possible to destroy the invalid shared class caches,
  and/or delete the cache control files. HOWEVER, this action will
  not prevent another recurrance of the situation.
  
  THEREFORE, It is highly recommended to disable the Shared
  Classes feature using the option above to prevent this issue
  from recurring as well as to bypass any invalid control files
  that may remain. (-Xshareclasses:none)
  
  
  J9D: 149704
  
  
  This defect will be fixed in Java 5.0 SR11
  

Problem summary

• Starting Multiple JVM?s at the same time resulted in a race to
  create a System V IPC semaphore. This race resulted in multiple
  semaphores (some un-initialized) being created, when only one
  initialized semaphore was expected. The extra un-initialized
  semaphores would cause JVM to hang.
  

Problem conclusion

• The JVM has been updated to properly handle multiple JVM's
  connecting to the same shareclasses cache.