Incinerator – Stale references detection and elimination

Get Complete Project Material File(s) Now! »

The Smart Home Properties

The smart home is a particular hardware and software environment. This section describes the main properties of the smart home, and describes the challenges introduced by each property. Each challenge raises a set of issues that need to be tackled. We detail those issues throughout this chapter, and we present existing solutions addressing them along with their limits.
Openness. Devices in a typical home are often created by different hardware manufacturers. Along with devices, applications running in the devices or supporting them are also developed by different software editors. The smart home inhabitants do not need to be locked to a particular vendor. This openness of the smart home to different tiers raises the need for an open smart home gateway that is able to host applications from different untrusted tiers.
Dynamicity. The smart home is dynamic at the hardware level, as different devices appear and disappear all the time, and several devices are movable. We expect the smart home to be dynamic also at the software level, where applications are installed, updated and uninstalled at a fast pace compared to the “up time” of the smart home gateway, which is a long-running system. Therefore, applications need to be designed to cope with this dynamic nature. Hot-swapping solves this issue by starting and stopping applications as necessary to cope with, not only hardware changes happening in the smart home, but also relatively frequent software updates and the continuous end-user desire to install new applications providing innovative services.
Rapid Development. Thanks to the wealth of devices present in it, the smart home offers new opportunities to service providers, who long to develop ubiquitous applications that take advantage of those devices, and of the physical proximity to the end-user. In order to catch the rising smart home market, and to enable faster innovation pace, the service providers want to rapidly develop and deploy services at the smart home. Rapid development needs simple tools and processes to manage applications life cycle, especially development tools and languages, without forgetting deployment and maintenance tools. Applications need to be easily created using reusable building blocks that can be composed quickly. These building blocks need to be loosely coupled in order to allow easy upgrades and maintenance. The component model is a set of rules and processes to easily compose applications out of basic building blocks called components, urging for code reuse and encapsulation. A component model also defines what is a component from what is not, and describes the process of creating individual components. The logic in each component is highly “encapsulated” inside it, and interaction between components only happens through interfaces, which implies that components are relatively independent of each other, making them good candidates for hot-swapping mechanisms. For these reasons, we believe that smart home applications should be developed based on a component model.
Heterogeneity. The devices and applications of the smart home have various capabilities for use by the home inhabitants. Some devices and applications provide different variations of the same capability, e.g., voice calling versus video calling. Other devices and applications provide different implementations of the same capability, e.g., voice calling via the Global System for Mobile Communications (GSM) network or voice calling via the Voice over Internet Protocol (VoIP). To cope with this heterogeneity, and in order for smart home applications to use these capabilities, the features provided by different tiers need to be standardized as contracts that are independent of their implementation details and vendors. This the reason smart home applications need to be service-oriented, based on standard interfaces, where a service can be defined as a contract-based controlled access mechanism to a set of capabilities. The Service-Oriented Architecture (SOA) [103, 78] allows applications and devices to provide and consume standard services independently of their vendors, implementations, etc.
Distributed Aspect. In order to provide fully integrated services to the end-user, often multiple devices and applications need to collaborate and communicate. The smart home devices and applications are often physically distant, and they are connected via diverse networking technologies of different scales, ranging from Personal Area Networks (PAN, e.g., Infrared, Bluetooth, ZigBee, Z-Wave) to Local Area Networks (LAN, e.g., Ethernet, WiFi) and even to Internet. This highlights the distributed nature of the smart home, where software running in devices, in the gateway and in the internet collaborate to offer smart services to the home inhabitants. This is why applications deployed on the smart home gateway and delivered by different smart home actors should be able to communicate easily.
Embedded Aspect. Constrained by its cost, the smart home gateway is an embedded system that has limited hardware resources. We expect the gateway to have a micro-controller or a micro-processor running at hundreds megahertz, using tens to hundreds megabytes of volatile and non-volatile memory. Existing affordable single-board computers such as the “Raspberry Pi” [108] and the “Arduino Yún” [6] already exhibit such performances. This reduces the choice of technologies allowing agile [17] software development, as some of these technologies induce high overheads that are not affordable under embedded constraints. For instance, Java [55] is one of the commonly used Object-Oriented technologies allowing agile software development. Java has several profiles suitable to different levels of embedded constraints, e.g., Java Mobile Information Device Profile (MIDP) [110], Java Connected Device Configuration (CDC) [36, 123], Java ME Embedded Profile [15], etc. One of the main component-based and service-oriented platforms based on Java and compatible with the embedded constraints is the OSGi [30, 127, 26, 82, 54] framework, which can be used to develop smart home applications. We also expect some smart home gateways to be further constrained, i.e., based on a micro-controller or a micro-processor running at tens megahertz, using hundreds kilobytes of volatile and non-volatile memory. For these gateways, virtual machines are often unaffordable, which raises the need for native applications. As an example, the MIND [92] framework, which is an implementation of the Fractal [29] component model, can be used to write native component-based applications.
The dynamic nature of the smart home raises the need for hot-swapping applications, i.e., loading, unloading and updating applications on the fly without the need to restart the platform. In order to perform hot-swapping, application code should be loadable into a running middleware platform, and unloadable when the application is no longer needed. The exact hot-swapping mechanism depends on the nature of the operator platform middleware and the applications hosted on it.
In this section, we focus on hot-swapping mechanisms for native and Java applications. First, we present position-independent code and how it can be used to load a native application into a running process. Then we define Java class loaders and the structure of Java references, which justifies the class loader unloading conditions in the Java virtual machine. Finally, we present a concrete example where these unloading conditions represent a conceptual and a technical lock for hot-swapping of dynamic Java applications: multi-tenant Java virtual machines.

Hot-swapping Native Applications

A native application is an application that directly uses the Instruction Set Architecture (ISA) [115] of the processors running the computer. By “directly”, we mean that no interpretation or binary translation is needed in order to run the application. In order to run a standalone native application, an operating system loads the application into memory in a dedicated virtual address space, i.e., a process, often at a specific base address dictated by the application binary meta-data. The machine code contained in the standalone application assumes that it is always loaded at the specified base address, and uses that assumption to calculate absolute addresses of functions and variables and embeds them into the application binary. Embedding of absolute addresses avoids unnecessary calculations of addresses at runtime, therefore improving application performances.
The constant base address assumption relies on the dedicated address space given by the process abstraction. Thus, applications that share the same address space generally cannot assume a constant base address, which obliges them to use relative addressing. Machine code that does not rely on a constant base address is called a Position-Independent Code (PIC) [63, 85, 128]. Position-independent code forms the basic mechanism through which many operating systems provide the ability to load machine code into a running process. The operating system dynamic loader loads the position-independent code into memory, then it performs necessary data initialization and linking with other required libraries. Loadable machine code units are called Shared Objects (.so) in UNIX and Linux, and called Dynamic-Link Libraries (.dll) in Windows.
Native applications generated in the form of loadable code units can be loaded by the operator platform middleware, based on the operating system facilities. Once loaded, the application code can be executed as any other code in the platform, so it can be started, stopped and called back when events occur.

Hot-swapping Java Applications

A Java application is distributed as a set of Java binary classes. A Java binary class is a collection of intermediate code, called Java byte code, and meta-data describing that byte code. The meta-data describe Java class name, fields information, methods information, etc. The Java byte code is a sequence of virtual instructions in the form of a UNiversal Computer-Oriented Language (UNCOL) [34, 116, 117, 89, 5] that conforms to a Virtual Instruction Set Architecture (V-ISA) defined by the Java virtual machine specifications [76].

Java Class Loaders

The standard mechanism to load Java binary classes into a running Java virtual machine is the Java class loader, which is a Java object whose purpose is to return a Java class instance (i.e., a java.lang.Class object) given a fully qualified class name1. The JVM specifications assert the existence of a primordial class loader provided by the JVM, and allows applications to define new class loaders. New class loaders can reuse a part of the functionality provided by the primordial class loader.
The Java virtual machine identifies a loaded class uniquely by its name and its class loader object, as follows: Lo dedC ss = hC ssLo derObject, C ssN me i. This identification implies that a class loader object defines a name space in which its classes are identified separately from the classes loaded by other class loaders. Therefore, two classes with the same name loaded on the same JVM instance using different class loaders are considered different types. This name space isolation enables loading multiple applications, each within a dedicated class loader, without risking naming conflicts.

Class Loader Unloading Conditions

In Java [55], an object reference is, by default, strong [119], i.e., the object reference not only gives access to the pointed-to object, but also guarantees that the object will not be collected by the garbage collector. In other words, an object will remain in memory as long as there is one or more strong references to it somewhere in the JVM. As strong references are the default reference type in Java, we refer to them simply as “references”, unless otherwise specified.
A garbage collection root is either a Java static reference (e.g., a Java class field, a thread-local variable) or a Java object reference in a running method (i.e., a method local variable).
A Java object is reachable if it can be accessed by traversing the object graph in some sort, starting from a garbage collection root, and following references.
Figure 1.2 shows that a Java object holds a reference to its class, and a class holds a reference to its class loader. Additionally, a class loader holds references to all the classes it loaded. The garbage collector [64] can collect an object when it becomes unreachable. Collecting a Java class C implies reclaiming the byte code of the methods of C , their generated machine code, and associated information, e.g., C ’s fully qualified name, hierarchy, and fields. Therefore:
Property 1.1 (Class loader collecting condition. See Figure 1.2.). A class loader L that loaded classes C1, …, CN can only be collected when the graph of objects {L, C1, …, CN} becomes unreachable, which implicitly requires that, for each C , all objects of C are unreachable.
Property 1.2 (Class loader lifetime). In Java [55], the lifetime of a class loader encompasses the lifetimes of all the classes it loads, i.e., a class loader is created before it can load classes, and it is collected after all its loaded classes get collected. Moreover, the lifetime of a class encompasses the lifetimes of all objects of the class, i.e., a class is loaded before any objects of it are created, and it is collected after all its objects get collected. Consequently, the lifetime of a class loader encompasses the lifetimes of all the classes it loads, and all objects of those classes.

READ  Perturbations and sharp interface: normal field

Hot-swapping in Multi-Tenant Java Virtual Machines

A Java virtual machine is called multi-tenant [62, 11] when it can run multiple Java applications in the same time. Multi-tenancy is often used when a system needs to run multiple Java applications, but due to hardware constraints, the system cannot run multiple Java virtual machines, one for each application.
In multi-tenant Java virtual machines, class loaders are often used to load entire applications. A given class loader will load every Java binary class composing the application on-demand, i.e., the first time the class is accessed. Due to Property 1.1, collecting classes only happens in bulk, i.e., all classes loaded by a class loader must be collected before the class loader itself can be collected. Practically speaking, a Java application loaded by a class loader can only be collected as a whole, with all its objects, classes, and the class loader itself, when all these become unreachable.
Consequently, if an application keeps a stale reference (i.e., an unneeded reference) to a second application that should be unloaded (for example, because it is being uninstalled), then the second application would never be reclaimed from memory, therefore causing a significant memory leak. This is why a system based on a multi-tenant Java virtual machine is vulnerable to stale references, especially when the system is required to run for long periods of time.

The Distributed Aspect of the Smart Home

A smart home application often needs to communicate with devices and with other applications, in order to compose services and provide an integrated experience to the end-user. Therefore, communication mechanisms need to be easy to use, and as fast as possible.
Communication mechanisms between applications depend on whether they can share memory or not. On one hand, applications that can share memory often can communicate using local procedure calls. On the other hand, applications that can only communicate via messages typically call each other using remote procedure calls. We briefly describe these two procedure call mechanisms in this section.
Local Procedure Calls. Two applications running in the same address space can communicate via local procedure calls. In order for an application to call a local procedure, the application must adhere to a specific calling convention [7] agreed upon by the procedure, e.g., standard call convention (stdcall), fast call convention (fastcall), C declaration call convention (cdecl), Pascal calling convention (pascal), etc. A calling convention describes the protocol of calling the local procedure, e.g., where and how arguments are passed, what exceptions can be thrown, what execution context is expected by the procedure, etc. The calling convention also describes the return protocol, i.e., how the procedure should return control to its caller. Calling a local procedure generally requires few processor cycles, which is relatively fast. Local procedure calls require memory sharing between the calling application and the called application, which is intrinsically possible when both applications run in the same address space.
Remote Procedure Calls. When applications cannot share memory, they cannot communicate using local procedure calls, and they rather use message-based communication mechanisms, such as remote procedure calls. In order for a procedure P1 in an application App1 to call a remote procedure P2 in an application App2, the following steps are usually required:
1. P1 calls a remote procedure proxy in App1, passing it the remote procedure information, e.g., remote application, procedure name, input parameters.
2. App1 serializes all the input parameters of P2 into a buffer B n. Serialization, a.k.a, marshaling, is the process of packing a list of parameters into a contiguous buffer suitable for sending in a message.
8 Koutheir Attouchi
4. Rapid Application Development in the Smart Home
3. App1 sends B n through a communication channel to App2, and waits for a reply from App2.
4. App2 receives B n, then it deserializes the buffer. Deserialization, a.k.a, unmarshaling is the process of extracting a list of parameters from a serialized buffer.
5. App2 calls P2 via a local procedure call, passing the parameters extracted from B n.
6. P2 returns control to App2.
7. App2 serializes all the output parameters of P2 into a buffer Bo t, then it sends the buffer through the communication channel to App1.
8. App1 receives Bo t, then it deserializes the buffer.
9. App1 then returns control to P1, passing it the output parameters extracted from Bo t.
Serialization is usually a significantly slow and expensive operation, especially compared to merely passing memory addresses in local procedure calls. In fact, a remote procedure call can be more than ten times slower than a local procedure call, as illustrated in Table 2.1 page 46. Examples of remote procedure protocols include Remote Procedure Calls (RPC) [118], Java Remote Method Invocation (RMI) [133], Distributed Component Object Model (DCOM) [75], Incommunicado [102], Internet Inter-ORB Protocol (IIOP) [39] based on the Common Object Request Broker Architecture (CORBA) [91].

Rapid Application Development in the Smart Home

Given the numerous devices present in it, the smart home offers new opportunities to many service providers, who plan to develop ubiquitous applications that take advantage of these devices, and of the physical proximity to the home inhabitants. To innovate fast, service providers need to be able to rapidly develop and deploy services at the smart home. This raises the need for simple tools and processes to manage applications life cycle, including development tools and languages, and deployment and maintenance tools. Developers should be able to easily create applications from reusable building blocks that can be composed quickly. These building blocks need to be loosely coupled in order to allow easy upgrades and maintenance.
The component model is a set of rules and processes to easily compose applications out of basic building blocks called components, urging for code reuse and encapsulation. Each component encapsulates a business logic that interacts with the platform and other components only through interfaces, therefore components are relatively standalone entities, making them easily hot-swappable. These are the reasons for choosing the component-based model as a design approach for smart home applications. In this section, we characterize the component model, then we present three examples of components models that are suitable for the smart home gateway.

The Component Model

As stated by Crnković et al. [38], different definitions of the concept of a software component exist in literature. The commonly used definition is the following:
Definition 1.3 (Software component, defined by Szyperski et al. [122]). “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party.”
There are two types of interfaces: (1) operation-based interfaces often used in software design, and (2) port-based interfaces, often used to design hardware systems [38]. As we focus our definitions on software design paradigms, we define an interface as a set of operations, a.k.a., methods. Each operation is identified by a name and a list of parameters that are input or output from the component providing the interface. Formally speaking:
The mp ement t on part shown in Definition 1.5 indicates that a component is executable, either directly on the machine, or through interpretation, or binary translation, etc. Unlike other executable units, the code of a component encapsulates its responsibilities and business logic, and it is limited to interacting with other components and with the platform. A component also includes meta-data describing itself, e.g., its identification, interfaces, properties, etc.
A component model, not only identifies what is a component from what is not one, but also describes the process of creating individual components and the rules to connect them to form a complete system. Figure 1.3 illustrates such a system, where two components are deployed on the platform. When a set of components also conforms to the component model, it is called a composite.

Table of contents :

1 State of the Art 
2 The Dynamicity of the Smart Home 
2.1 Hot-swapping Native Applications
2.2 Hot-swapping Java Applications
3 The Distributed Aspect of the Smart Home
4 Rapid Application Development in the Smart Home
4.1 The Component Model
4.2 The Fractal Component Model
4.3 The OSGi Component Model
4.4 The OSGi Declarative Services Component Model
5 The Heterogeneity of the Smart Home 
5.1 The Service-Oriented Architecture
5.2 OSGi as a Service-Oriented Architecture
6 The Open and Embedded Aspects of the Smart Home 
6.1 Isolation based on Hardware Protection and Virtualization
6.2 Isolation based on Language Type Safety
6.3 Discovering Resource Sharing Conflicts via Monitoring
6.4 Stale References – A Typical Source of Memory Conflicts
7 Conclusion 

GET THE COMPLETE PROJECT

Related Posts