Incinerator - Eliminating Stale References in Dynamic OSGi Applications - K Attouchi & A Bottaro
17
Wednesday 29 th of October 2014 1 Incinerator Koutheir ATTOUCHI 1,2 , Gaël THOMAS 1 , André BOTTARO 2 , Gilles MULLER 1 1 Laboratoire d’Informatique de Paris 6, France. 2 Orange Labs, Grenoble, France. Detecting & Resolving Stale References in Java
-
Upload
mfrancis -
Category
Technology
-
view
122 -
download
4
description
OSGi Community Event 2014 Abstract: 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 http://hal.inria.fr/hal-00952327. An industrial perspective of this
Transcript of Incinerator - Eliminating Stale References in Dynamic OSGi Applications - K Attouchi & A Bottaro
Wednesday 29th of October 2014 1
Incinerator
Koutheir ATTOUCHI1,2, Gaël THOMAS1, André BOTTARO2, Gilles MULLER1 1 Laboratoire d’Informatique de Paris 6, France. 2 Orange Labs, Grenoble, France.
Detecting & Resolving Stale References in Java
Wednesday 29th of October 2014 2
The Smart Home Multiple Application Domains
§ Security
§ Energy
§ Healthcare
§ Comfort
§ Well being
§ Multimedia
§ Content sharing
§ Games
Wednesday 29th of October 2014 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 4
Home Automation Gateway Offered by a Smart Home Operator
One common embedded platform § Hosting applications delivered by various tiers1
1 Condry et al. (IECON’99); Royon and Frénot (2007)
Objectives § Reduce service
deployment costs
§ Share connected devices between tiers
Wednesday 29th of October 2014 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 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
O1 Object in App1 Object in App2 O2 Reference Stale Reference
O2
App2 uninstalled ! O2 stale
Wednesday 29th of October 2014 7
Smart Home Alarm Application Motivation by an example
Alarm Application
GasSensor Driver Siren Driver 1.0
Siren Configuration (Format: Simple Text)
Gas Sensor Alarm Siren
Siren Configuration (Format: XML)
Stale Reference Siren Driver 2.0
3
1
2 1
2
3
Update Siren Driver è version 2.0 Convert Siren configuration format è XML Forget to update the reference to Siren Driver 1.0
1
3
2
1
3
2
Memory leak Data corruption Physical hazard
Wednesday 29th of October 2014 8
Significant Memory Leak Caused by Stale References1
O1
1 Lindholm and Yellin (1999); Johnson and Dawson (2014)
S
C2 C4
C3 Class(S)
ClassLoader(S)
Stale reference
Stale object
Wednesday 29th of October 2014 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 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
O2
S2
O3
S1
O4
Stale reference Stale object
Wednesday 29th of October 2014 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
O3
S1
O4
Stale reference Stale object
F1
Defer
Unreachable finalizable object
Wednesday 29th of October 2014 12
Synchronization Issues when Eliminating Stale References
Incinerator
T1 T2 T3
S1
T1, T2 and T3 synchronize on the monitor of S1
Stale reference Stale object Active thread Blocked thread
T3 and T2 blocked forever
Wednesday 29th of October 2014 13
Synchronization Handling when Eliminating Stale References
T1 T2 T3
S1
Stale reference Stale object Active thread Blocked thread
Incinerator
Wake up!
Monitor(S1) " Stale Monitor(S1) = Stale
! NPE
! NPE
Wake up! ! NPE
Wednesday 29th of October 2014 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 – http://llvm.org/svn/llvm-project/vmkit/branches/incinerator/
1 Geoffray et al. (VEE’10) 2 Makewave AB Corp. (2014)
Wednesday 29th of October 2014 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 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 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
Thank you!
