Bug ID: JDK-6809158 JVM crashed running IdM when zone was configured with "dedicated-cpu: ncpus: 1-2"

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: solaris_10u6

Priority: P3
Status: Closed
Resolution: Won't Fix
OS: solaris_10
CPU: x86

Submitted: 2009-02-24
Updated: 2010-10-07
Resolved: 2009-06-09

Customer reported the following behavior:

On Solaris 10 x86 U 6 (Solaris 10 8/07 w/ 137112-07) intermittent JVM crashes 
are observed, running Sun IdM, when the zone is configured like follows:

zonecfg: dedicated-cpu:
                          ncpus: 1-2

The issues are no longer reproducible on the same box, when the zone is
configured like follows:

zonecfg: rctl:
                     name: zone.cpu-shares
                     value: (priv=privileged,limit=25,action=none)

The relationship between failure and configuration of the zone was 
verified on two separate boxes several times.

WORK AROUND Always start the VM with more than one processor available. This can be dropped back to one once the VM has been initialized.
13-05-2009
EVALUATION The JVM is not resource pool aware. Using zones as described involves resource pools: dedicated-cpu: ncpus, importance The number of CPUs that should be assigned for this zone's exclusive use. The zone will create a pool and processor set when it boots. this may cause the JVM to think it has a different number of processors available to it than it actually has. In the general case this would cause VM ergonomics to misconfigure the JVM and affect performance. In a particular case, as Keith mentions in the comments, if the VM thinks it only has one processor available then it will configure itself to use code sequences that exclude synchronization operations needed on SMP systems. If it turns out there are more processors available, or if later more processors become available, then the code will be incorrect and crashes are likely. Corrected to add: this does not affect simple use of processor sets, without pools, as execution in a processor set does not change the value returned by sysconf(_SC_NPROCESSORS_CONF) - hence the VM will always be configured for multi-processor support on a MP system, even if executed in a processor set with only 1 processor. (Which is itself a minor bug.)
13-05-2009
SUGGESTED FIX Simplest: add a flag -XX:+ForceMultiprocessorSupport that causes os::is_MP() to return true regardless of the number of processors. More complicated: use the existence of an initial processor set, or resource pool to force os::is_MP() to return true.
13-05-2009
PUBLIC COMMENTS The JVM is not resource pool aware. Using zones as described involves resource pools: dedicated-cpu: ncpus, importance The number of CPUs that should be assigned for this zone's exclusive use. The zone will create a pool and processor set when it boots. this may cause the JVM to think it has a different number of processors available to it than it actually has. In the general case this would cause VM ergonomics to misconfigure the JVM and affect performance. In a particular case, as Keith mentions in the comments, if the VM thinks it only has one processor available then it will configure itself to use code sequences that exclude synchronization operations needed on SMP systems. If it turns out there are more processors available, or if later more processors become available, then the code will be incorrect and crashes are likely.
17-03-2009