SWE 622 Final Project Presentation – Team 1

1. SWE 622 Final Project Presentation – Team 1 Yanyan Zhu Virat Kadaru Koji Hashimoto Stephanie Buchner

2. What we planned to do • Support both RMI and PToP communication simultaneously during operation • Middleware component handles communication • Application component handles application logic • Flexible configuration • Testing over a VPN • Evaluation using AspectJ

3. Project Design Overview Exchange List of Traders List of Goods Trader List of Exchanges List of Orders ConnectionFailed(callback) Send(async.) Receive(callback) Middleware ProcessingThread : rmi/p2p : msg HeartbeatThread SendingThread ReceivingThread RMI PToP ConnectionThread

4. What we have done! • Support both RMI and PToP communication simultaneously during operation • Middleware component handles communication • Application component handles application logic • Flexible configuration • Testing over a VPN • Problems with RMI and VPN • PToP works perfectly over VPN • Evaluation using AspectJ

5. Configuration • RMI – Pure RMI communication • Ex – Exchange Override • Tr – Trader Override • Mix – Mixed Config (Message Override) • PToP – Pure PToP communication • PToP-VPN – Pure PToP communication over VPN

6. Report • *Time taken to send orders and do other activities • Roundtrip time • Latency & offsets (local) • Latency & offsets (remote) • Failure Detection time • Memory footprint

11. Memory Footprint Measurements • How many Traders can an Exchange keep track of without running out of memory? • Size of NodeInfo object • How many Order Echoes can a Trader store before running out of memory? • Size of Order object

12. Memory FootprintMethodology 1. Obtain estimate of object size. Use programs that measure object size ObjectSizer from Java Practices - http://www.javapractices.com/topic/TopicAction.do?Id=83 Sizeof from Javaworld, Vladimir Roubtsov http://www.javaworld.com/javaworld/javatips/jw-javatip130.html 2. Validate the estimate. Create objects until memory runs out. Calculate the size of the objects based on the number of objects created before OutOfMemory error occurs.

13. Memory FootprintMethodology cont’d Program approach: • Run finalizers and gc • freeMemory = Runtime.totalMemory() – Runtime.freeMemory(); • heap1 = freeMemory before creating objects; • Create n objects • heap2 = freeMemory after creating objects; • Create a number of objects • Size of object = (heap2 - heap1) / object count Program differences: Different tactics to force garbage collection.

14. Memory FootprintMethodology cont’d ObjectSizer gc approach: privatestaticlong getMemoryUse(){ putOutTheGarbage(); long totalMemory = Runtime.getRuntime().totalMemory(); putOutTheGarbage(); long freeMemory = Runtime.getRuntime().freeMemory(); return (totalMemory - freeMemory); } privatestaticvoid putOutTheGarbage() { collectGarbage(); collectGarbage(); }  privatestaticvoid collectGarbage() { try { System.gc(); Thread.currentThread().sleep(fSLEEP_INTERVAL); System.runFinalization(); Thread.currentThread().sleep(fSLEEP_INTERVAL); }

15. Memory FootprintMethodology cont’d Sizeof gc approach: privatestaticvoid runGC () throws Exception { // for whatever reason it helps to call Runtime.gc() // using several method calls: for (int r = 0; r < 4; ++ r) _runGC (); }  privatestaticvoid _runGC () throws Exception { long usedMem1 = usedMemory (), usedMem2 = Long.MAX_VALUE; for (int i = 0; (usedMem1 < usedMem2) && (i < 1000); ++ i) { s_runtime.runFinalization (); s_runtime.gc (); Thread.currentThread ().yield (); usedMem2 = usedMem1; usedMem1 = usedMemory (); } } privatestaticlong usedMemory () { returns_runtime.totalMemory () - s_runtime.freeMemory (); }

16. Memory Footprint Estimate Object Size • ObjectSizer results using different sample sizes: • Sizeof results using different sample sizes:

17. Memory FootprintMemory Use Estimates Estimated memory threshold: Total Memory - Base Heap Size / Estimated Size = Estimated Total Objects Average Base Heap Size = 107,888 + 107,528 / 2 = 107,558 Estimated memory thresholds for Order Echo objects: • 524288000 – 107558 / 124.5 = 4,210,284 According to ObjectSizer • 524288000 – 107558 / 128 = 4,095,159 According to Sizeof Estimated memory thresholds for Trader NodeInfo objects on the Exchange: • 524288000 – 107558 / 125.50 = 4,176,736 According to ObjectSizer • 524288000 – 107558 / 127.75 = 4,103,173 According to Sizeof

18. Memory FootprintValidate Estimate Approach: • Measure the number of objects that can be created before getting an OutOfMemory error at a particular max heap size setting: 500 MB • Set JVM max heap size to -Xmx500M   • Create numbers of Order Echo and Trader NodeInfo objects, using the estimates as a baseline. • Actual Object Size = Total Memory – Base Heap Size / Actual Total Objects

19. Memory FootprintValidate Estimate cont’d Results for Order Echoes on Trader Expected threshold = 4,095,159 - 4,210,284 Actual = 4,195,019 Actual size of Order Echo Objects: 524288000 – 107558 / 4,195,019 419501=~125 bytes

20. Memory FootprintValidate Estimate cont’d

21. Memory FootprintValidate Estimate cont’d

22. Memory FootprintValidate Estimate cont’d Results for Trader NodeInfo on Exchange Expected threshold = 4,103,173 - 4,176,736 Actual = 4,195,520 Actual size of Order Echo Objects: 524288000 – 107558 / 4,195,020 419501=~125 bytes

23. Memory FootprintValidate Estimate cont’d

24. Memory FootprintValidate Estimate cont’d

25. Memory FootprintConclusions • The Sizeof program gave a consistent and conservative estimate of the object size. Actual Objects – Sizeof Estimate / Actual Objects = Margin of Error of Sizeof Est 4,195,519 - 4,095,159 = 100,360 100,360 / 4,195,519 = +.024% • Outstanding question: Why is Sizeof result larger than measured actual size? Issue with Sizeof gc approach, or measurment of actual results? • ObjectSizer garbage collection approach issues: Inconsistent results indicate problems with gc approach. Calling gc before getting total and also before getting free memory is a the problem.

26. Level of Effort

27. Demo

28. Questions