United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-5048379 API for obtaining low-level CPU information (e.g., socket count and CPU model)
JDK-5048379 : API for obtaining low-level CPU information (e.g., socket count and CPU model)

Details
Type:
Enhancement
Submit Date:
2004-05-17
Status:
Open
Updated Date:
2010-10-04
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
windows_xp,windows_2000
Sub-Component:
java.lang
CPU:
x86
Priority:
P3
Resolution:
Unresolved
Affected Versions:
1.4.2_06,6u22
Targeted Versions:

Related Reports

Sub Tasks

Description
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 " +
            rt.availableProcessors());

    }

}

                                    

Comments
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
                                     
2004-05-19



Hardware and Software, Engineered to Work Together