4. Dynamic Linking

MobiiliohjelmointiMobiiliohjelmointiKevät 2009Kevät 2009

11

4. Dynamic Linking4. Dynamic Linking

• OverviewOverview• Implementation techniquesImplementation techniques• PluginsPlugins• Managing memory consumptionManaging memory consumption• Using DLLsUsing DLLs• Mobile Java implementationMobile Java implementation• Symbian OS implementation Symbian OS implementation

– DLL structureDLL structure– ECOMECOM

• SummarySummary


22

MotivationMotivation

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

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

• Smaller compilations and deliveries; smaller Smaller compilations and deliveries; smaller upgradesupgrades

• Flexible compositionFlexible composition• Enables focused testingEnables focused testing• Scoping of system management (smallest unit Scoping of system management (smallest unit

addressed in e.g. build or release management)addressed in e.g. build or release management)• Work allocation Work allocation


33

Dynamically linked librariesDynamically linked libraries

Single application file Multiple files that are loaded dynamically

Before loading After loading


44

Release Definition with DLLsRelease Definition with DLLs

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

• Defines all the necessary elements for a complete Defines all the necessary elements for a complete systemsystem

• Enables early toolchain development as well as Enables early toolchain development as well as decomposition of the system into different decomposition of the system into different subsystemssubsystems– Test of the build systemTest of the build system

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


55

Required Implementation Required Implementation FacilitiesFacilities

• Dynamic capabilities for …Dynamic capabilities for …– Loading Loading – UnloadingUnloading– Selection if several possibilities existSelection if several possibilities exist

• Copy in processes’ own memory vs. in-place Copy in processes’ own memory vs. in-place executionexecution– Data must be instantiated in any caseData must be instantiated in any case

• RestrictionsRestrictions– All code should not be active all the time; memory All code should not be active all the time; memory

related problems (e.g. fragmentation) if numerous related problems (e.g. fragmentation) if numerous loading of libraries of different sizesloading of libraries of different sizes


66

Static and Dynamic DLLsStatic and Dynamic DLLs

• Static DLLStatic DLL– (Commonly) Instantiated at application startup(Commonly) Instantiated at application startup– Resides in the memory until the application Resides in the memory until the application

terminatesterminates

• Dynamic DLL (often referred to as a plugin)Dynamic DLL (often referred to as a plugin)– Loaded and unloaded whenever neededLoaded and unloaded whenever needed– E.g. different plugin for different messaging types E.g. different plugin for different messaging types

(email/SMS/MMS)(email/SMS/MMS)


77

ChallengesChallenges

• Fragmentation of the system into an unmanageable Fragmentation of the system into an unmanageable collection of DLLscollection of DLLs– VersioningVersioning– Number of allowed configurationsNumber of allowed configurations– Number of accidentally created configurationsNumber of accidentally created configurations– Fractal-like use of pluginsFractal-like use of plugins

• Benefits of application-specific DLLs?Benefits of application-specific DLLs?• Interface compatibility when market requirements Interface compatibility when market requirements

force to change hardware characteristicsforce to change hardware characteristics– Platform continuity by freezing the interface for some period of Platform continuity by freezing the interface for some period of

timetime


88

Content and goalsContent and goals

• OverviewOverview• Implementation techniquesImplementation techniques• PluginsPlugins• Managing memory consumptionManaging memory consumption• Using DLLsUsing DLLs• Mobile Java implementationMobile Java implementation• Symbian OS implementation Symbian OS implementation


• SummarySummary


99

Implementing DLLsImplementing DLLs

DLL

Externalinterface

Code

Code

Code


1010

Option 1: Offset based CallsOption 1: Offset based Calls

DLL (support for plugins)APP

LIB Ordinal

Code

Code

Code


1111

Option 2: Using Method Option 2: Using Method SignaturesSignatures

DLL

Externalinterface

Code

Code

CodemethodX()methodY(int i, j)methodZ(string myName)


1212

ComparisonComparison

• Offset based linking isOffset based linking is– more efficient (no need to look for the method)more efficient (no need to look for the method)– more error-prone (what happens when somebody more error-prone (what happens when somebody

adds a new method?)adds a new method?)

• Signature based linking isSignature based linking is– more natural (one can call methods from different more natural (one can call methods from different

libraries with ease)libraries with ease)– more memory hungry (signatures must be saved more memory hungry (signatures must be saved

somewhere)somewhere)


1313


• OverviewOverview• Implementation techniquesImplementation techniques• PluginsPlugins• Managing DLL memory consumptionManaging DLL memory consumption• Using DLLsUsing DLLs• Mobile Java implementationMobile Java implementation• Symbian OS implementation Symbian OS implementation


• SummarySummary


1414

Plugin PrinciplePlugin Principle

Pluginimplementations

P1

Application

P2

P3 P1

Application

P3

P2

Application

P2

P3

P1

No pluginsloaded

Plugin P2loaded

Plugin P2 unloadedand P1 loaded

Plugininterface




1515

Abstract Factory as Abstract Factory as Implementation mechanismImplementation mechanism

<<interface>>AbsDLLAClient

<<interface>>AbsDLLB

<<interface>>AbsFactory

ConcFactory1 ConcFactory2

CreateProductACreateProductB

CreateDLLACreateDLLB

CreateDLLACreateDLLB

ConcDLLA1 ConcDLLA2 ConcDLLB1 ConcDLLB2

operAxoperAy

operBxoperBy


1616

Infrastructure and implementation Infrastructure and implementation level concernslevel concerns

• Loading and unloading frameworkLoading and unloading framework• Resolution Resolution

– Searching and selecting the right pluginSearching and selecting the right plugin

• Policy for registering and removing of plugins to Policy for registering and removing of plugins to enable dynamic creation of new (or improved) enable dynamic creation of new (or improved) featuresfeatures– Who should be able to do this?Who should be able to do this?– Compatibility issuesCompatibility issues

• Plugin use can also introduce side-effectsPlugin use can also introduce side-effects– E.g. Response to a messageE.g. Response to a message


1717




• SummarySummary


1818

PrinciplesPrinciples

1.1. Always use the simplest structure you really need!Always use the simplest structure you really need!2.2. Make all DLLs (and DLL developers) responsible Make all DLLs (and DLL developers) responsible

for the memory they allocatefor the memory they allocate• Needed for realistically defining a release and its resource Needed for realistically defining a release and its resource

consumption in any case!consumption in any case!

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

• Desk exercise to get the first estimateDesk exercise to get the first estimate• Running real code as soon as possible to get more Running real code as soon as possible to get more

realistic figures on actual performancerealistic figures on actual performance


1919

Merging software and data Merging software and data elements as the last resortelements as the last resort

• Merging packages and DLLsMerging packages and DLLs– Reduces overhead of referring to the methods of Reduces overhead of referring to the methods of

the packages/DLLsthe packages/DLLs

• Flattening hierarchiesFlattening hierarchies– Reduces the number of identifiers, reduces the Reduces the number of identifiers, reduces the

number of virtual function tablesnumber of virtual function tables

• Embedding objectsEmbedding objects– Alters the layout of the data structureAlters the layout of the data structure


2020

Example: Embedded PointersExample: Embedded Pointers

next objectref

next objectref

next objectref

object

object

object

objectnext

objectnext

objectnext


2121




• SummarySummary


2222

Rules of Thumb for DLL CreationRules of Thumb for DLL Creation

• Shareable componentShareable component• Variation or management point Variation or management point

– Several different implementations (or alternatives)Several different implementations (or alternatives)

• Test process requirements Test process requirements – Testing needs a concrete subjectTesting needs a concrete subject– Automated testing with binary deliveriesAutomated testing with binary deliveries

• End product of an organizational unitEnd product of an organizational unit– Release management can be eased if Release management can be eased if

compilations are not to be managed as a part of itcompilations are not to be managed as a part of it– Black-box subcontractingBlack-box subcontracting


2323


• OverviewOverview• Implementation techniquesImplementation techniques• PluginsPlugins• Managing DLL memory consumptionManaging DLL memory consumption• Using DLLsUsing DLLs• Mobile Java implementationMobile Java implementation• Symbian OS implementationSymbian OS implementation


• SummarySummary


2424

Mobile Java and DLLsMobile Java and DLLs

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

• Linking is a built-in feature at class levelLinking is a built-in feature at class level– Performed automatically for a complete class -> Performed automatically for a complete class ->

Smaller classes have certain advantagesSmaller classes have certain advantages– Class memory overhead -> Larger classes have Class memory overhead -> Larger classes have

certain advantagescertain advantages• No support for plugins due to CLDC No support for plugins due to CLDC

restrictionsrestrictions– More capable mobile systems can include also More capable mobile systems can include also

support for plugins; not a technical impossibility in support for plugins; not a technical impossibility in mobile settingmobile setting


2525

Average Class File Content Average Class File Content (CLDC library classes)(CLDC library classes)

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

(about half is debug info)(about half is debug info)

– Strings 34.8%Strings 34.8%

– Bytecode 19.1%Bytecode 19.1%

– Class field data 0.4%Class field data 0.4%

– Instance field data 0.4%Instance field data 0.4%


2626

Effect of compression and Effect of compression and different application structuresdifferent application structures

FormatFormat 14 classes14 classes 1 class1 class

No compressionNo compression 14019 14019 7467 7467

No compression, obfuscatedNo compression, obfuscated 13093 13093 6929 6929

JARJAR 10111 10111 3552 3552

Jar ObfuscatedJar Obfuscated 10048 10048 3540 3540

PackPack 4563 4563 3849 3849

Pack.gzPack.gz 2568 2568 2235 2235


2727

Effect of compression and library Effect of compression and library structuresstructures

FormatFormat Size (bytes)Size (bytes)

ClassesClasses 111694111694JARJAR 76517 76517PackPack 43233 43233Pack.gzPack.gz 23791 23791tar.gztar.gz 46099 46099JXEJXE 104919104919


2828

Library ConsiderationsLibrary Considerations

• Prelinking of most commonly used standard librariesPrelinking of most commonly used standard libraries– Only interface must be visible Only interface must be visible – Internals can be implemented as e.g. a part of the virtual Internals can be implemented as e.g. a part of the virtual

machinemachine– Uses more memory, but linking/loading becomes easierUses more memory, but linking/loading becomes easier

• Structure considerationsStructure considerations– JARring class by class cannot benefit from recurring JARring class by class cannot benefit from recurring

constructs (e.g. constructors in every class)constructs (e.g. constructors in every class)


2929

Also programmer actions matter!Also programmer actions matter!

public void push(Object e) {public void push(Object e) { ensureCapasity(); // Check slots countensureCapasity(); // Check slots count elements[size++] = e;elements[size++] = e;}}

public Object pop() {public Object pop() { if (size == 0) throw new EmptyStackException();if (size == 0) throw new EmptyStackException(); return elements[--size];return elements[--size];}}

• Ok?Ok?


3030

Stack

size

Objects stored in Stack

Object stackObject stack


3131

Stack/Vector

size

Objects stored in Stack

Objects stored in Vectorbut not in Stack

Leaking AbstractionLeaking Abstraction


3232

UpgradeUpgrade

public Object pop() {public Object pop() {

if (size == 0) if (size == 0)

throw new EmptyStackException();throw new EmptyStackException();

Object result = elements[--size];Object result = elements[--size];

elements[size] = null;elements[size] = null;

return result; return result;

}}


3333

Rules of Thumb for Mobile JavaRules of Thumb for Mobile Java

• Avoid small classesAvoid small classes• Avoid dependenciesAvoid dependencies• Select size when relevant and manage Select size when relevant and manage

vector/string usagevector/string usage• Consider using array vs. using vectorConsider using array vs. using vector• Use stringBuffer when possibleUse stringBuffer when possible• Manage class and object structureManage class and object structure• Generate less garbageGenerate less garbage• Consider obfuscationConsider obfuscation• Handle array initializationHandle array initialization


3434

Example 1Example 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)); }}


3535

ResultsResults

• ArrayImp (minimal overhead)ArrayImp (minimal overhead)– Bytes: 8016Bytes: 8016– Objects: 1 Objects: 1

• VectorImp (integers wrapped to objects)VectorImp (integers wrapped to objects)– Bytes: 40000Bytes: 40000– Objects: 2002Objects: 2002

• VectorImpSimple (failures in guessing the size)VectorImpSimple (failures in guessing the size)– Bytes: 52000Bytes: 52000– Objects: 2010Objects: 2010[Hartikainen: Java application and library memory consumption, TUT, 2005][Hartikainen: Java application and library memory consumption, TUT, 2005]


3636

Example 2Example 2

static final int AMOUNT = 100;static final int AMOUNT = 100;

public void useString() {public void useString() { String s = “”;String s = “”; for(int i = 0; i < AMOUNT; i++) {for(int i = 0; i < AMOUNT; i++) { s = s + “a”;s = s + “a”; }}}}

public void useStringBuffer() {public void useStringBuffer() { String s = “”;String s = “”; StringBuffer sb = new StringBuffer(AMOUNT);StringBuffer sb = new StringBuffer(AMOUNT); for(int i = 0; i < AMOUNT; i++) {for(int i = 0; i < AMOUNT; i++) { sb = sb.append(“a”);sb = sb.append(“a”); }} s = sb.toString();s = sb.toString();}}


3737

ResultsResults

• UseString (simplest)UseString (simplest)– Bytes: 39000Bytes: 39000– Objects: 450Objects: 450

• UseStringBuffer (optimized)UseStringBuffer (optimized)– Bytes: 304Bytes: 304– Objects: 5Objects: 5

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


3838

Example 3Example 3

• A sample application consisting of 14 A sample application consisting of 14 classes was refactored into a form classes was refactored into a form where only 1 calss was used without where only 1 calss was used without altering the behavioraltering the behavior– 14 classes: 1401914 classes: 14019– 1 class: 74671 class: 7467

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


3939


• OverviewOverview• Implementation techniquesImplementation techniques• PluginsPlugins• Managing DLL memory consumptionManaging DLL memory consumption• Using DLLsUsing DLLs• Mobile Java implementationMobile Java implementation• Symbian OS implementationSymbian OS implementation


• SummarySummary


4040

Offset-based linkingOffset-based linking

DLL (support for plugins)APP

LIB Ordinal

Code

Code

Code


4141

Expressed in Code with Macros Expressed in Code with Macros (IMPORT_C, EXPORT_C)(IMPORT_C, EXPORT_C)

class CQAEng : public CBase class CQAEng : public CBase {{public:public: IMPORT_C static CQAEng* NewL();IMPORT_C static CQAEng* NewL(); ........protected:protected: CQAEng(); CQAEng(); ........};};

EXPORT_C CQAEng * CQAEng::NewL()EXPORT_C CQAEng * CQAEng::NewL() {{ CQAEng* self = CQAEng* self = new (ELeave) CQAEng;new (ELeave) CQAEng; CleanupStack::PushL(self);CleanupStack::PushL(self); self->ConstructL();self->ConstructL(); CleanupStack::Pop();CleanupStack::Pop(); return self;return self; }}

CQAEng::CQAEng()CQAEng::CQAEng() {{ iQuestion = 0;iQuestion = 0; iAnswer = 0;iAnswer = 0; iUsed = EFalse;iUsed = EFalse; }}


4242

Managing Binary CompatibilityManaging Binary Compatibility• AbsoluteAbsolute

– Do not change the size of a class objectDo not change the size of a class object– Do not remove anything accessibleDo not remove anything accessible– Do not rearrange accessible class member dataDo not rearrange accessible class member data– Do not rearrange the ordinal of exported functionsDo not rearrange the ordinal of exported functions– Do no re-order virtual functionsDo no re-order virtual functions– Do not modify documented semantics of APIDo not modify documented semantics of API– Do not remove Do not remove constconst– Do not change from pass by value to pass by reference, or vice Do not change from pass by value to pass by reference, or vice

versaversa• Future-proofFuture-proof

– Do not inline functionsDo not inline functions– Do not expose public or protected member dataDo not expose public or protected member data– Allow object initialization to leaveAllow object initialization to leave– Override virtual functions that are expected to be overridden in the Override virtual functions that are expected to be overridden in the

futurefuture– Provide ”spare” member dataProvide ”spare” member data


4343

Programmer OptionsProgrammer Options

• API extensionsAPI extensions• Private internals of a class can be modifiedPrivate internals of a class can be modified• Access specification can be relaxedAccess specification can be relaxed• Pointers can be substituted with references and vice Pointers can be substituted with references and vice

versaversa• Names of exported non-virtual functions can be Names of exported non-virtual functions can be

modifiedmodified• Input can be widened and output can be narrowedInput can be widened and output can be narrowed• Specifier Specifier const const can be appliedcan be applied


4444




• SummarySummary


4545

ECOM FrameworkECOM Framework

Interfaceclient

Interface(CCryptoIF)

Implementation(CCryptoSW)

Implementation(CCryptoSW)

NewL

ECOMFramework

REComSession::CreateImplementationL

Implements

Resolves andinstantiates


4646

ECOM Interface RequirementsECOM Interface Requirements

• Abstract class with a set of one or more pure virtual Abstract class with a set of one or more pure virtual functionsfunctions

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

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

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


4747




• SummarySummary


4848

SummarySummary

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

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

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

• Plugins are special DLLs that can be dynamically Plugins are special DLLs that can be dynamically loaded and unloadedloaded and unloaded– Common interfaceCommon interface– Implementation for the interfaceImplementation for the interface– Framework for loading the interfaceFramework for loading the interface

Documents

4. Dynamic Linking