|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Objectbb.util.MemoryMonitor.UnitTest
public static class MemoryMonitor.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 |
MemoryMonitor.UnitTest.ListenerTest
Simple subclass of MemoryMonitorListenerImpl which can be interrogated to see if events have occured. |
Field Summary | |
---|---|
private static long |
interval_test
Contract: this constant always has the smallest possible value allowed for MemoryMonitor.interval , namely 1. |
Constructor Summary | |
---|---|
MemoryMonitor.UnitTest()
|
Method Summary | |
---|---|
void |
benchmark_impactOfMonitoring()
Results on 2009-03-16 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_11 server jvm):
Benchmarking task with no monitoring of memory... |
private static void |
printExtraTime(double timeNoMon,
double timeMon,
double sd)
|
void |
test_onMemoryXXX()
|
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_onMemoryXXX
as well as the impact of monitoring in benchmark_impactOfMonitoring
.
Constructor Detail |
---|
public MemoryMonitor.UnitTest()
Method Detail |
---|
public void test_onMemoryXXX() throws Exception
Exception
public void benchmark_impactOfMonitoring() throws InterruptedException
Benchmarking task with no monitoring of memory...
task first = 11.278 ms, mean = 7.722 ms (CI deltas: -1.224 us, +1.550 us), sd = 86.509 us (CI deltas: -17.095 us, +36.614 us) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE
Benchmarking task while monitoring memory but with NO MemoryMonitorListeners...
task first = 7.708 ms, mean = 7.723 ms (CI deltas: -887.239 ns, +923.811 ns), sd = 57.218 us (CI deltas: -8.818 us, +13.918 us) WARNING: execution times have mild outliers, SD VALUES MAY BE INACCURATE
Extra execution time due to monitoring: 1.0437390625004858 us = 0.012065113074846893 standard deviations (of the original measurement)
Benchmarking task while monitoring memory AND with a simple MemoryMonitorListener...
task first = 8.621 ms, mean = 7.726 ms (CI deltas: -1.353 us, +1.511 us), sd = 90.391 us (CI deltas: -13.799 us, +20.687 us) WARNING: execution times have mild outliers, SD VALUES MAY BE INACCURATE
Extra execution time due to monitoring: 4.475211393229622 us = 0.05173125490178093 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 modest impact.)
One issue: when the memory state file that is produced by the listener while task runs was examined,
it only contained 4,069 entries.
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.
InterruptedException
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 |