How many hardware details can a Java Applet Discover?

Question

I'm writing a Java applet to run differently under different hardware. For instance if I know a computer has a large amount of RAM but a weak processor, I can alter the balance of some time-memory trade-offs. Being able to discover the exact make and model of the CPU on which the applet is running could be helpful. Having such information would allow me to benchmark my software against different systems and find bottlenecks.

Generally what I'm looking for is:

• Number of cores and/or processors
• 32 bit vs 64 bit CPU
• CPU Cache line size
• Size of L1, L2, L3 cache
• Set associativity of cache
• Size of TLB
• Exact Make/Model information on the CPU
• FSB information
• Amount of RAM
• Amount of swap/virtual memory
• The JVM in which the applet is being run
• Operating System running JVM
• System Load
• Number of used/unused Kernal threads
• Bandwidth of internet connection
• Memory available
• Graphics cards in use
• If Operating System is being visualised
• Network resource in use

Is any of this information baked into Java Applets. Are there libraries for finding any of this information? Applet benchmarking tools to discover/guess some of it? Any clever tricks you can think of?

Are their any aspects of computer hardware which are blocking. That is, could a Java applet detect that something is in use or unavailable by trying to access it and being denied (maybe a particular TCP port or graphics accelerator).

Disclaimer: I know that caring about the hardware goes against the Java ideology of not caring about the hardware. While comments point this out may be helpful for other readers that see this question, please note that such answers are not what I am looking for.

EDIT

Added additional information:

java.lang.management provides all sorts of information on the system which the JVM is running on.

java.lang.management.OperatingSystemMXBean provides:

1. getAvailableProcessors() The number of available processors equivalent Runtime.availableProcessors()
2. getSystemLoadAverage() The average load on the system the system load average for the last minute.

java.lang.management.ManagementFactory

1. getGarbageCollectorMXBeans() returns a list ofGarbageCollectorMXBeans. Each GarbageCollectorMXBean can be queried for the following information:

   1. getCollectionCount() number of gc which have occured using this bean.
   2. getCollectionTime() approximate accumulated time elapsed between gc's in milliseconds. (Note: The Java virtual machine implementation may use a high resolution timer to measure the elapsed time.)
   3. getName() the name of the memory manager.
   4. getMemoryPoolNames() the memory pools that this gc manages.

2. getThreadMXBean() returns the ThreadMXBean which provides:

   1. getCurrentThreadCpuTime() Returns the total CPU time for the current thread in nanoseconds. If the implementation distinguishes between user mode time and system mode time, the returned CPU time is the amount of time that the current thread has executed in user mode or system mode.
3. getRuntimeMXBean returns RuntimeMXBean
   1. getUptime() uptime of the Java virtual machine in milliseconds.
   2. getStartTime() start time of the Java virtual machine in milliseconds.
   3. getInputArguments() Returns the input arguments passed to the Java virtual machine which does not include the arguments to the main method.
4. getCompilationMXBean returns the CompilationMXBean
   1. getName() the name of the JIT
   2. getTotalCompilationTime() time in milliseconds it took to compile your code.

Answer 1

The ones that are quite simple to obtain are the information accessible via the System.getProperties (or System.getProperty) method.

For example, os.name will return the name of the operating system. On my system, I got the Windows XP as the result.

Some information available by System.getProperties, which seems to be accessible by the applet include:

• java.vm.version -- version of the JVM.
• java.vm.vendor -- vendor name of the JVM.
• java.vm.name -- name of the JVM.
• os.name -- name of the operating system. (e.g. Windows XP)
• os.arch -- architecture of system. (e.g. x86)
• os.version -- version of the operating system. (e.g. 5.1)
• java.specification.version -- JRE specification version.

The above is not a comprehensive list, but it can give some ideas about what the system is like.

It should be noted that not all properties that are available through the System.getProperties can be read, as for some properties, the security manager will cause an AccessControlException. When I tried to read the java.home property, an exception was thrown.

To obtain those properties which cause a AccessControlException by default, one would probably would have to be steps taken to give permissions to the applet to perform some of those information. (Here is a link to the Security Restrictions section of the Lesson: Applets from The Java Tutorials.)

The Runtime class can provide information such as:

• Number of processors (or cores, or logical threads, presumably) available to the JVM by the Runtime.availableProcessors method.
• Java virtual machine's memory information, such as freeMemory, maxMemory, and totalMemory.

Beyond the information provided by the default System and Runtime classes would probably require making calls to the operating system, which would be platform-dependent.

Edit

The Getting System Properties page from Lesson: Applets of The Java Tutorials provides a list of properties which can be read, and a list of properties that cannot be read by applets.

Answer 2

Here are some more:

java.awt.Toolkit may be able to tell the screen resolution and maybe even something more about the graphic card (from the used color model).

You can also allocate some bigger array of bytes and measure access times to get approximate information about the cache (in the past we played with this to check if memory cache tricks work with Java at all; they do). However these tests may hang your applet for some time so you need to inform the user that your are doing.

Applets that do modelling can measure the ratio of passed virtual time over the passed real time. After detecting a slow system, the applet can increase integration step and similar constants to requires less CPU time, even with the expense of the less perfect output. Here there is an example of such self tuning code that adjusts the step speed in the simulation of the bird flock behavior.