|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Objectbb.util.ThreadMonitor.UnitTest
public static class ThreadMonitor.UnitTest
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 |
---|
private static final long interval_test
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
.
Constructor Detail |
---|
public ThreadMonitor.UnitTest()
Method Detail |
---|
public void test_onXXX() throws Exception
Exception
public void benchmark_impactOfMonitoring() throws Exception
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.
Exception
private static void printExtraTime(double timeNoMon, double timeMon, double sd)
|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |