bb.util
Class ThreadMonitor.UnitTest

java.lang.Object
  extended by bb.util.ThreadMonitor.UnitTest
Enclosing class:
ThreadMonitor

public static class ThreadMonitor.UnitTest
extends Object

See the Overview page of the project's javadocs for a general description of this unit test class.


Nested Class Summary
private static class ThreadMonitor.UnitTest.ListenerTest
          Simple ThreadMonitorListener implementation meant for test purposes: it prints all events to System.out (except for onThreadState, which outputs to ThreadMonitor.UnitTest.ListenerTest.pw), it uses ThreadMonitor.UnitTest.ListenerTest.barrier to coordinate actions with the main thread, and onThreadState can be configured to deliberately throw a RuntimeException when makeFail called.
private static class ThreadMonitor.UnitTest.ThreadMeasurerTest
          Extends ThreadMeasurer to deliberately throw a RuntimeException when makeFail called.
 
Field Summary
private static long interval_test
          Contract: this constant always has the smallest possible value allowed for MemoryMonitor.interval, namely 1.
 
Constructor Summary
ThreadMonitor.UnitTest()
           
 
Method Summary
 void benchmark_impactOfMonitoring()
          Results on 2009-03-16 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_11 server jvm): Benchmark of task with no monitoring of threads...
private static void printExtraTime(double timeNoMon, double timeMon, double sd)
           
 void test_onXXX()
           
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Field Detail

interval_test

private static final long interval_test
Contract: this constant always has the smallest possible value allowed for MemoryMonitor.interval, namely 1. Reason: this stresses both the correctness testing of the code in test_onXXX as well as the impact of monitoring in benchmark_impactOfMonitoring.

See Also:
Constant Field Values
Constructor Detail

ThreadMonitor.UnitTest

public ThreadMonitor.UnitTest()
Method Detail

test_onXXX

public void test_onXXX()
                throws Exception
Throws:
Exception

benchmark_impactOfMonitoring

public void benchmark_impactOfMonitoring()
                                  throws Exception
Results on 2009-03-16 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_11 server jvm):

                        Benchmark of task with no monitoring of threads...
                        task first = 11.376 ms, mean = 8.826 ms (CI deltas: -1.960 us, +2.169 us), sd = 92.218 us (CI deltas: -14.265 us, +21.880 us) WARNING: execution times have mild outliers, SD VALUES MAY BE INACCURATE

                        Benchmarking task while monitoring threads but with NO ThreadMonitorListeners...
                        task first = 11.208 ms, mean = 10.096 ms (CI deltas: -833.043 ns, +966.141 ns), sd = 40.019 us (CI deltas: -5.339 us, +3.472 us) WARNING: SD VALUES MAY BE INACCURATE
                        Extra execution time due to monitoring: 1.2692279098958318 ms = 13.763310986781851 standard deviations (of the original measurement)

                        Benchmarking task while monitoring threads AND with a simple ThreadMonitorListener...
                        task first = 10.159 ms, mean = 10.096 ms (CI deltas: -886.358 ns, +1.093 us), sd = 43.350 us (CI deltas: -5.941 us, +12.268 us) WARNING: SD VALUES MAY BE INACCURATE
                        Extra execution time due to monitoring: 1.2693616809895773 ms = 13.764761579815543 standard deviations (of the original measurement)
 

It seems clear that monitoring the memory has very little impact on a cpu intensive operation. (Note: this result was obtained on jdk 6, but when previously tested it on jdk 5, found a major impact.)

One issue: when the memory state file that is produced by the listener while task runs was examined, it only contained 182,001 lines ~= 3,000 entries (assuming ~60 lines per entry). Given that interval is being set to interval_test = 1 ms, would have expected ~40 * 1000 ~= 40,000 entries if the monitoring task truly was executed every millisecond. Since writing to the file perhaps takes more than 1 ms, maybe that is part of the explanation. Another factor might be that my PC's clock is so inaccurate that it can only schedule with resolutions down to 10-20 ms.

Throws:
Exception

printExtraTime

private static void printExtraTime(double timeNoMon,
                                   double timeMon,
                                   double sd)