The code for active_processor_count, used by Runtime.availableProcessors() is as follows:

int os::active_processor_count() {
  int online_cpus = sysconf(_SC_NPROCESSORS_ONLN);
  pid_t pid = getpid();
  psetid_t pset = PS_NONE;
  // Are we running in a processor set?
  if (pset_bind(PS_QUERY, P_PID, pid, &pset) == 0) {
    if (pset != PS_NONE) {
      uint_t pset_cpus;
      // Query number of cpus in processor set
      if (pset_info(pset, NULL, &pset_cpus, NULL) == 0) {
	assert(pset_cpus > 0 && pset_cpus <= online_cpus, "sanity check");
	_processors_online = pset_cpus;
	return pset_cpus;
      }
    }
  }
  // Otherwise return number of online cpus
  return online_cpus;
}

This code correctly queries if the current process is being executed in a processor set, but incorrectly ignores the possibility that a processor set exists which is not being used by the VM. For example, if a system has active 32 processors and 8 have been dedicated to a processor set (not used by the VM) then the current code will report 32 available processors when it should report 24.

While this is simple to fix (remove the check for (pset != PS_NONE)) there are compatability concerns here because applications which have been tuned based on the incorrect value returned by availableProcessors(), will suddenly behave differently if the correct value is returned. 

Also note that while the code supports processor sets, it does not support pools - something that might need to be addressed in the future.

In the real-time VM we have also discovered that if threads within the VM are bound to specific processor sets (not used by the VM as a whole) then the pset_bind(PS_QUERY, PPID, ...) call can return incorrect results. While not an issue for current HS, it may be an issue if native code tries to manipulate thread bindings directly, or if the VM is embedded in a process that uses processor bindings for threads that attach to the VM.

Finally, the use of the _processors_online global needs to re-examined. It's use seems to be related to a 1.3.1 issue relating to early Solaris versions that are hopefully now anicent history.
A flag will be needed to restore the current broken behaviour to address the compatability issue.
Should be prominently documented in release notes to point out compatibility
issue pointed out above.
Note the comment re pools above is not correct. The code does account for pools correctly because when pools are active sysconf(_SC_NPROCESSORS_ONLN) returns the current number of processors in the processor-set of the pool.