4. Dynamic Linking

concretecakeΠολεοδομικά Έργα

29 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

76 εμφανίσεις



Mobiiliohjelmointi

Kevät 2009


1

4. Dynamic Linking


Overview


Implementation techniques


Plugins


Managing memory consumption


Using DLLs


Mobile Java implementation


Symbian OS implementation


DLL structure


ECOM


Summary




Mobiiliohjelmointi

Kevät 2009


2

Motivation


Several applications use the same code; no need to
include it in all applications separately


Application
-
specific tailoring in cases where similar
functions are needed (plugins)


Smaller compilations and deliveries; smaller
upgrades


Flexible composition


Enables focused testing


Scoping of system management (smallest unit
addressed in e.g. build or release management)


Work allocation



Mobiiliohjelmointi

Kevät 2009


3

Dynamically linked libraries

Single application file

Multiple files that are loaded dynamically

Before loading

After loading



Mobiiliohjelmointi

Kevät 2009


4

Release Definition with DLLs


First action to take in the beginning of the
development of a new (or enhanced) system


Defines all the necessary elements for a complete
system


Enables early toolchain development as well as
decomposition of the system into different
subsystems


Test of the build system


Some parts can be left open for future extensions
(plugins)



Mobiiliohjelmointi

Kevät 2009


5

Required Implementation
Facilities


Dynamic capabilities for …


Loading


Unloading


Selection if several possibilities exist


Copy in processes’ own memory vs. in
-
place
execution


Data must be instantiated in any case


Restrictions


All code should not be active all the time; memory
related problems (e.g. fragmentation) if numerous
loading of libraries of different sizes



Mobiiliohjelmointi

Kevät 2009


6

Static and Dynamic DLLs


Static DLL


(Commonly) Instantiated at application startup


Resides in the memory until the application
terminates


Dynamic DLL (often referred to as a plugin)


Loaded and unloaded whenever needed


E.g. different plugin for different messaging types
(email/SMS/MMS)



Mobiiliohjelmointi

Kevät 2009


7

Challenges


Fragmentation of the system into an unmanageable
collection of DLLs


Versioning


Number of allowed configurations


Number of accidentally created configurations


Fractal
-
like use of plugins


Benefits of application
-
specific DLLs?


Interface compatibility when market requirements
force to change hardware characteristics


Platform continuity by freezing the interface for some period of
time



Mobiiliohjelmointi

Kevät 2009


8

Content and goals


Overview


Implementation techniques


Plugins


Managing memory consumption


Using DLLs


Mobile Java implementation


Symbian OS implementation


DLL structure


ECOM


Summary




Mobiiliohjelmointi

Kevät 2009


9

Implementing DLLs

DLL

External

interface

Code

Code

Code



Mobiiliohjelmointi

Kevät 2009


10

Option 1: Offset based Calls

DLL (support for plugins)

APP

LIB

Ordinal

Code

Code

Code



Mobiiliohjelmointi

Kevät 2009


11

Option 2: Using Method
Signatures

DLL

External

interface

Code

Code

Code

methodX()

methodY(int i, j)

methodZ(string myName)



Mobiiliohjelmointi

Kevät 2009


12

Comparison


Offset based linking is


more efficient (no need to look for the method)


more error
-
prone (what happens when somebody
adds a new method?)


Signature based linking is


more natural (one can call methods from different
libraries with ease)


more memory hungry (signatures must be saved
somewhere)



Mobiiliohjelmointi

Kevät 2009


13

Content and goals


Overview


Implementation techniques


Plugins


Managing DLL memory consumption


Using DLLs


Mobile Java implementation


Symbian OS implementation


DLL structure


ECOM


Summary




Mobiiliohjelmointi

Kevät 2009


14

Plugin Principle

Plugin

implementations

P1

Application

P2

P3

P1

Application

P3

P2

Application

P2

P3

P1

No plugins

loaded

Plugin P2

loaded

Plugin P2 unloaded

and P1 loaded

Plugin

interface

Plugin

implementations

Plugin

implementations



Mobiiliohjelmointi

Kevät 2009


15

Abstract Factory as
Implementation mechanism

<<interface>>

AbsDLLA

Client

<<interface>>

AbsDLLB

<<interface>>

AbsFactory

ConcFactory1

ConcFactory2

CreateProductA

CreateProductB

CreateDLLA

CreateDLLB

CreateDLLA

CreateDLLB

ConcDLLA1

ConcDLLA2

ConcDLLB1

ConcDLLB2

operAx

operAy

operBx

operBy



Mobiiliohjelmointi

Kevät 2009


16

Infrastructure and implementation
level concerns


Loading and unloading framework


Resolution


Searching and selecting the right plugin


Policy for registering and removing of plugins to
enable dynamic creation of new (or improved)
features


Who should be able to do this?


Compatibility issues


Plugin use can also introduce side
-
effects


E.g. Response to a message



Mobiiliohjelmointi

Kevät 2009


17

Content and goals


Overview


Implementation techniques


Plugins


Managing DLL memory consumption


Using DLLs


Mobile Java implementation


Symbian OS implementation


DLL structure


ECOM


Summary




Mobiiliohjelmointi

Kevät 2009


18

Principles

1.
Always use the simplest structure you really need!

2.
Make all DLLs (and DLL developers) responsible
for the memory they allocate


Needed for realistically defining a release and its resource
consumption in any case!

3.
When in doubt, consider what will eventually
happen at the level of implementation


Desk exercise to get the first estimate


Running real code as soon as possible to get more
realistic figures on actual performance



Mobiiliohjelmointi

Kevät 2009


19

Merging software and data
elements as the last resort


Merging packages and DLLs


Reduces overhead of referring to the methods of
the packages/DLLs


Flattening hierarchies


Reduces the number of identifiers, reduces the
number of virtual function tables


Embedding objects


Alters the layout of the data structure



Mobiiliohjelmointi

Kevät 2009


20

Example: Embedded Pointers

next

object

ref

next

object

ref

next

object

ref

object

object

object


object

next


object

next


object

next



Mobiiliohjelmointi

Kevät 2009


21

Content and goals


Overview


Implementation techniques


Plugins


Managing DLL memory consumption


Using DLLs


Mobile Java implementation


Symbian OS implementation


DLL structure


ECOM


Summary




Mobiiliohjelmointi

Kevät 2009


22

Rules of Thumb for DLL Creation


Shareable component


Variation or management point


Several different implementations (or alternatives)


Test process requirements


Testing needs a concrete subject


Automated testing with binary deliveries


End product of an organizational unit


Release management can be eased if
compilations are not to be managed as a part of it


Black
-
box subcontracting



Mobiiliohjelmointi

Kevät 2009


23

Content and goals


Overview


Implementation techniques


Plugins


Managing DLL memory consumption


Using DLLs


Mobile Java implementation


Symbian OS implementation


DLL structure


ECOM


Summary




Mobiiliohjelmointi

Kevät 2009


24

Mobile Java and DLLs


All class files can be considered as more or
less similar to DLLs


Linking is a built
-
in feature at class level


Performed automatically for a complete class
-
>
Smaller classes have certain advantages


Class memory overhead
-
> Larger classes have
certain advantages


No support for plugins due to CLDC
restrictions


More capable mobile systems can include also
support for plugins; not a technical impossibility in
mobile setting



Mobiiliohjelmointi

Kevät 2009


25

Average Class File Content
(CLDC library classes)


Measurements by Hartikainen (Java application and library
memory consumption, MSc thesis, Tampere U of Tech, 2005):


Metadata 45.4%

(about half is debug info)


Strings 34.8%


Bytecode 19.1%


Class field data 0.4%


Instance field data 0.4%



Mobiiliohjelmointi

Kevät 2009


26

Effect of compression and
different application structures

Format




14 classes



1 class


No compression



14019



7467

No compression, obfuscated


13093



6929

JAR





10111



3552

Jar Obfuscated




10048



3540

Pack





4563



3849

Pack.gz





2568



2235




Mobiiliohjelmointi

Kevät 2009


27

Effect of compression and library
structures

Format





Size (bytes)


Classes





111694

JAR






76517

Pack






43233

Pack.gz






23791

tar.gz






46099

JXE





104919



Mobiiliohjelmointi

Kevät 2009


28

Library Considerations


Prelinking of most commonly used standard libraries


Only interface must be visible


Internals can be implemented as e.g. a part of the virtual
machine


Uses more memory, but linking/loading becomes easier


Structure considerations


JARring class by class cannot benefit from recurring
constructs (e.g. constructors in every class)




Mobiiliohjelmointi

Kevät 2009


29

Also programmer actions matter!

public void push(Object e) {


ensureCapasity(); // Check slots count


elements[size++] = e;

}


public Object pop() {


if (size == 0) throw new EmptyStackException();


return elements[
--
size];

}



Ok?





Mobiiliohjelmointi

Kevät 2009


30

Stack

size

Objects stored in Stack

Object stack



Mobiiliohjelmointi

Kevät 2009


31

Stack/Vector

size

Objects stored in Stack

Objects stored in Vector

but not in Stack

Leaking Abstraction



Mobiiliohjelmointi

Kevät 2009


32

Upgrade

public Object pop() {


if (size == 0)


throw new EmptyStackException();


Object result = elements[
--
size];


elements[size] = null;


return result;

}




Mobiiliohjelmointi

Kevät 2009


33

Rules of Thumb for Mobile Java


Avoid small classes


Avoid dependencies


Select size when relevant and manage
vector/string usage


Consider using array vs. using vector


Use stringBuffer when possible


Manage class and object structure


Generate less garbage


Consider obfuscation


Handle array initialization



Mobiiliohjelmointi

Kevät 2009


34

Example 1

static final int SIZE = 2000;


private void arrayImp() {


numbers = new int[SIZE];


for (int i = 0; i < SIZE; i++) { numbers[i] = i; }

}


private void vectorImp() {


numberV = new Vector(SIZE);


for (int i = 0; i < SIZE; i++) { numberV.addElement(new Integer(i)); }

}


private void vectorImpSimple() {


numberV2 = new Vector(); // Default size


for (int i = 0; i < SIZE; i++) { numberV2.addElement(new Integer(i)); }

}




Mobiiliohjelmointi

Kevät 2009


35

Results


ArrayImp (minimal overhead)


Bytes: 8016


Objects: 1


VectorImp (integers wrapped to objects)


Bytes: 40000


Objects: 2002


VectorImpSimple (failures in guessing the size)


Bytes: 52000


Objects: 2010

[Hartikainen: Java application and library memory consumption, TUT, 2005]



Mobiiliohjelmointi

Kevät 2009


36

Example 2

static final int AMOUNT = 100;


public void useString() {


String s = “”;


for(int i = 0; i < AMOUNT; i++) {


s = s + “a”;


}

}


public void useStringBuffer() {


String s = “”;


StringBuffer sb = new StringBuffer(AMOUNT);



for(int i = 0; i < AMOUNT; i++) {


sb = sb.append(“a”);


}


s = sb.toString();

}




Mobiiliohjelmointi

Kevät 2009


37

Results


UseString (simplest)


Bytes: 39000


Objects: 450


UseStringBuffer (optimized)


Bytes: 304


Objects: 5


[Hartikainen: Java application and library memory consumption, TUT, 2005]




Mobiiliohjelmointi

Kevät 2009


38

Example 3


A sample application consisting of 14
classes was refactored into a form
where only 1 calss was used without
altering the behavior


14 classes: 14019


1 class: 7467


[Hartikainen: Java application and library memory consumption, TUT, 2005]




Mobiiliohjelmointi

Kevät 2009


39

Content and goals


Overview


Implementation techniques


Plugins


Managing DLL memory consumption


Using DLLs


Mobile Java implementation


Symbian OS implementation


DLL structure


ECOM


Summary




Mobiiliohjelmointi

Kevät 2009


40

Offset
-
based linking

DLL (support for plugins)

APP

LIB

Ordinal

Code

Code

Code



Mobiiliohjelmointi

Kevät 2009


41

Expressed in Code with Macros
(IMPORT_C, EXPORT_C)

class CQAEng : public CBase


{

public:


IMPORT_C static CQAEng* NewL();


....

protected:


CQAEng();


....

};

EXPORT_C CQAEng * CQAEng::NewL()


{


CQAEng* self =


new (ELeave) CQAEng;


CleanupStack::PushL(self);


self
-
>ConstructL();


CleanupStack::Pop();


return self;


}


CQAEng::CQAEng()


{


iQuestion = 0;


iAnswer = 0;


iUsed = EFalse;


}



Mobiiliohjelmointi

Kevät 2009


42

Managing Binary Compatibility


Absolute


Do not change the size of a class object


Do not remove anything accessible


Do not rearrange accessible class member data


Do not rearrange the ordinal of exported functions


Do no re
-
order virtual functions


Do not modify documented semantics of API


Do not remove
const


Do not change from pass by value to pass by reference, or vice
versa


Future
-
proof


Do not inline functions


Do not expose public or protected member data


Allow object initialization to leave


Override virtual functions that are expected to be overridden in the
future


Provide ”spare” member data



Mobiiliohjelmointi

Kevät 2009


43

Programmer Options


API extensions


Private internals of a class can be modified


Access specification can be relaxed


Pointers can be substituted with references and vice
versa


Names of exported non
-
virtual functions can be
modified


Input can be widened and output can be narrowed


Specifier
const
can be applied



Mobiiliohjelmointi

Kevät 2009


44

Content and goals


Overview


Implementation techniques


Plugins


Managing DLL memory consumption


Using DLLs


Mobile Java implementation


Symbian OS implementation


DLL structure


ECOM


Summary




Mobiiliohjelmointi

Kevät 2009


45

ECOM Framework

Interface

client

Interface

(CCryptoIF)

Implementation

(CCryptoSW)

Implementation

(CCryptoSW)

NewL

ECOM

Framework

REComSession::CreateImplementationL

Implements

Resolves and

instantiates



Mobiiliohjelmointi

Kevät 2009


46

ECOM Interface Requirements


Abstract class with a set of one or more pure virtual
functions


Provides one or more factory functions to allow the
client to instantiate an interface implementation
object


Provides means for clients to release it (e.g.
destructor, Release, Close, ...)


TUid data member, which is used internally to identify
an implementation instance for cleanup purposes



Mobiiliohjelmointi

Kevät 2009


47

Content and goals


Overview


Implementation techniques


Plugins


Managing DLL memory consumption


Using DLLs


Mobile Java implementation


Symbian OS implementation


DLL structure


ECOM


Summary




Mobiiliohjelmointi

Kevät 2009


48

Summary


Dynamically linked libraries offer a way to save
memory, as code can be shared by several units


It is also possible to use DLLs to management
purposes (e.g. release definition and management)


Linking can be based on e.g. method signatures
(Java) or offset (Symbian OS)


Plugins are special DLLs that can be dynamically
loaded and unloaded


Common interface


Implementation for the interface


Framework for loading the interface