JDK-5048379 : API for obtaining low-level CPU information (e.g., socket count and CPU model)
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.4.2_06,6u22
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2004-05-17
  • Updated: 2016-05-20
Related Reports
Relates :  
The following code when run on Windows platform, normally returns the correct
results. But when we use the intel's hyperthreading then it returns twice the
number of processors available.

The reason is that java.lang.Runtime.availableProcessors() is returning the
number of logical processors, rather than the physical ones.

import java.lang.Runtime.*;

public class FindProcessor
    public static void main(String argv[]) {
	Runtime rt = java.lang.Runtime.getRuntime();
	System.out.println("The available processors are " +



Re-opened as this has nothing to do with 6515172. This is a request for some kind of physical topology based API for "processor" information.

Resolved by 6515172

EVALUATION Runtime.availableProcessors is a native call which simply turns around and calls JVM_ActiveProcessorCount(). -- iag@sfbay 2004-05-17 While it's true that a logical processor is not the same thing as a physical processor, there are cases where one wants to know the number of logical processors in the system. Changing the current behavior would also risk breaking existing code, so perhaps it'd be preferable define a new method to return the number of physical processors (availableProcessorCores?). -- ###@###.### 2004/5/17 Microsoft encountered the analogous issue in the win32 API. See http://www.microsoft.com/whdc/system/CEC/HT-windows.mspx. In response they added the GetLogicalProcessorInformation() API. GetSystemInfo() continues to return the # of logical processors. We shold follow suite in the Java APIs. Changing availableProcessors() to return the # of physical processors wold be a mistake. Such a policy would differ from the native policies used on Windows, Linux and Solaris. (The basic APIs on all those platforms return the # of logical processors). In addition, if the JVM were to return the # of physical processors we would risk underprovisioning thread pools and underutilizating the available processors. (Some Java applications create groups of worker threads, where the group size is proportional to the # of processors). Note that if an appropriate native API such as GetLogicalProcessorInformation() is not available, executing CPUID(1) to the read the logical_processors_per_physical_processors field from the APICID will also work. This presumes homogenous systems, but that's probably reasonable, although Intel and Microsoft are hinting that they may eventually support irregular MP systems. Similarly, the customer could easily work around this problem with JNI calls to a native routine that (a) probed for and called GetLogicalProcessorInformation(), or, (b) executed CPUID(1). Regarding the name of of the new, putative, Java method. We should take care that the name is in accordance with both Intel's terminology and Sun's CMP terminology. Sun's CMP glossary, for example, strongly recommends against using the term "core". ###@###.### 2004-05-19 I'm lowering this RFE to P3. We'll look at this for the next feature release. -- ###@###.### 2004/5/20