Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Incinerator - Eliminating Stale References in Dynamic OSGi Applications - K Attouchi & A Bottaro


Published on

OSGi Community Event 2014

OSGi technology has been chosen as the software execution environment for technical reasons on Enterprise servers and Smart Home gateways. However, one challenge needs to be tackled in the technology to build a robust framework: the well-known problem of stale references. This problem leads to memory leaks in some typical situations and is hard to detect, to track and to tackle by developers. The talk introduces the problem and describes Incinerator, a solution that we built and tested with open source Java virtual machine and OSGi framework.

Stale references are a common issue in platforms that support hot-swapping. Hot-swapping enables updating or uninstalling applications without restarting the platform. In normal situations, when an application is uninstalled, all other applications remove their references to it, in order to allow the platform to remove the uninstalled application from memory. However, if a buggy application keeps holding a reference to the uninstalled application, then that reference is called a stale reference. The stale reference forces the platform to keep the uninstalled application in memory, thus causing a significant memory leak. If the buggy application tries to use the uninstalled application via its stale reference, then the results are undefined, and the states of running applications can become inconsistent, because the uninstalled application does not expect to be invoked after it has executed its termination routines during its uninstallation event.

To solve this problem, we created Incinerator, a Java virtual machine extension that detects stale references and removes them. After hot-swapping an application, Incinerator investigates all references in the platform, looking for stale references. When a stale reference is found, Incinerator removes it, and disallows the buggy application from using that reference in the future, and allows cleanup to occur normally with minimal disruption. By finding stale references, Incinerator helps developers debug this problem which is hard to perceive. By removing stale references, Incinerator not only lowers the risk of state inconsistency, but also avoids the memory leak caused by stale references, thus allowing the platform to continue normal execution without running out of memory.

This work first targeted a business case within Orange: an OSGi platform shared by multiple untrusted applications on the home gateway. The Incinerator prototype was tested using Knopflerfish, one of the main open-source OSGi implementations for embedded home gateways. Thanks to Incinerator, we discovered and fixed a stale reference bug in open source bundles. Incinerator has a low overhead of at most 3.3% on average on the applications of the DaCapo benchmark suite. This shows that Incinerator is reasonable for use in production environments. The full experiment is described at An industrial perspective of this

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Incinerator - Eliminating Stale References in Dynamic OSGi Applications - K Attouchi & A Bottaro

  1. 1. Incinerator Detecting & Resolving Stale References in Java Koutheir ATTOUCHI1,2, Gaël THOMAS1, André BOTTARO2, Gilles MULLER1 1 Laboratoire d’Informatique de Paris 6, France. 2 Orange Labs, Grenoble, France. Wednesday 29th of October 2014 1
  2. 2. The Smart Home Multiple Application Domains § Security § Energy § Healthcare § Comfort § Well being § Multimedia § Content sharing § Games Wednesday 29th of October 2014 2
  3. 3. The Smart Home Connected devices Devices are § Connected § Easy to install § Affordable § Fridge § Thermostat § Fork § Oven § etc. Connected devices § Toothbrush § Washing machine § Scale § Locks § Dishwasher Wednesday 29th of October 2014 3
  4. 4. Home Automation Gateway Offered by a Smart Home Operator One common embedded platform § Hosting applications delivered by various tiers1 Objectives § Reduce service deployment costs § Share connected devices between tiers 1 Condry et al. (IECON’99); Royon and Frénot (2007) Wednesday 29th of October 2014 4
  5. 5. Hypothesis Unreliable and long-running applications § Applications can be – Buggy – Malicious § The platform runs for long duration § Abrupt restarts of the platform can be dangerous for – Devices – Inhabitants Wednesday 29th of October 2014 5
  6. 6. Addressed Issues Resolve stale references in Java applications Stale reference § A reference to a stale object: an object that became unusable – Many objects become unusable after updates and uninstallation of applications StaRlef Rereefnecreen ce Object in App1 O1 Object in App2 Wednesday 29th of October 2014 6 O2 App2 uninstalled ! O2 stale
  7. 7. Smart Home Alarm Application Motivation by an example Gas Sensor 1 Stale Reference Siren Driver 2.0 GasSensor Driver Siren Driver 1.0 Alarm Application Siren Configuration (Format: Simple Text) Wednesday 29th of October 2014 7 Alarm Siren (Format: XML) 3 1 2 3 Update Siren Driver è version 2.0 Convert Siren configuration format è XML Forget to update the reference to Siren Driver 1.0 3 2 1 2 Memory leak Data corruption Physical hazard
  8. 8. Significant Memory Leak Caused by Stale References1 O1 C2 C4 ClassLoader(S) S 1 Lindholm and Yellin (1999); Johnson and Dawson (2014) Wednesday 29th of October 2014 8 C3 Class(S) Stale reference Stale object
  9. 9. Significant Memory Leak Caused by Stale References Memory leaks caused by stale references appearing after multiple updates of a buggy application Wednesday 29th of October 2014 9
  10. 10. Incinerator Approach § Detect and eliminate* stale references § Incinerator transforms stale references to null references during garbage collection cycle * The Devil is in the Details… Incinerator O1 Wednesday 29th of October 2014 10 O2 S2 S1 O3 O4 Stale reference Stale object
  11. 11. Cleaning up resources in Object.finalize() Objective: § Allow objects to cleanup their resources – Execute Object.finalize() without risking exceptions due to stale references § Incinerator allows unreachable finalizable objects to hold stale references – Defer stale references elimination to the following garbage collection cycle Incinerator Defer Unreachable finalizable object Wednesday 29th of October 2014 11 S1 O3 O4 F1 Stale reference Stale object
  12. 12. Synchronization Issues when Eliminating Stale References Incinerator S1 T1 T2 T3 T1, T2 and T3 synchronize and T2 blocked on forever the monitor of S1 Stale reference Stale object Active thread Blocked thread Wednesday 29th of October 2014 12
  13. 13. Synchronization Handling when Eliminating Stale References MMoonniittoorr((SS11)) "= S Sttaalele S1 Incinerator Wake up! T1 T2 T3 ! Wake up! NPE ! NPE ! NPE Stale reference Stale object Active thread Blocked thread Wednesday 29th of October 2014 13
  14. 14. Implementation § 1000 lines of C++ in the J3/VMKit1 JVM § Tested on Knopflerfish2, an open source recognized implementation of OSGi – 10 lines added to Knopflerfish § Independent of the garbage collector algorithm § Open source – 1 Geoffray et al. (VEE’10) 2 Makewave AB Corp. (2014) Wednesday 29th of October 2014 14
  15. 15. Functional Evaluation Micro benchmarks § 10 scenarios of stale references, divided by: – Visibility from the OSGi framework – Scope of stale references – Synchronization on stale references – Finalization of objects holding stale references § Stale references detection results Scenario 1 2 3 4 5 6 7 8 9 10 J3/Hotspot û û û û û û û û û û Service Coroner1 ü û û û û û û û û û Incinerator ü ü ü ü ü ü ü ü ü ü § Incinerator also eliminates all detected stale references 1 Gama and Donsez (SEAA’08) Wednesday 29th of October 2014 15
  16. 16. Performance Evaluation DaCapo1 benchmark suite Low-end computer High-end computer Average cost in execution time of DaCapo test suites on J3 and on Incinerator Execution cost < 4% 1 Blackburn et al. (OOPSLA’06) Wednesday 29th of October 2014 16
  17. 17. Conclusion Incinerator § Incinerator detects and eliminates stale references, avoiding: – Memory leaks – Data corruption – Physical hazards § And makes stale references visible to Java/OSGi developers § Execution cost < 4% è Tolerable in: – Constrained production environments – Test environments § Implementation is mostly independent of: – The OSGi framework implementation – The garbage collection algorithm Wednesday 29th of October 2014 17 Thank you!