1. Mobiiliohjelmointi Kevät 2009 1 4. Dynamic Linking OverviewOverview Implementation techniquesImplementation techniques PluginsPlugins Managing memory consumptionManaging memory consumption Using DLLsUsing DLLs Mobile Java implementationMobile Java implementation Symbian OS implementationSymbian OS implementation –DLL structure –ECOM SummarySummary

2. Mobiiliohjelmointi Kevät 2009 2 Motivation Several applications use the same code; no need to include it in all applications separatelySeveral 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)Application-specific tailoring in cases where similar functions are needed (plugins) Smaller compilations and deliveries; smaller upgradesSmaller compilations and deliveries; smaller upgrades Flexible compositionFlexible composition Enables focused testingEnables focused testing Scoping of system management (smallest unit addressed in e.g. build or release management)Scoping of system management (smallest unit addressed in e.g. build or release management) Work allocationWork allocation

3. Mobiiliohjelmointi Kevät 2009 3 Dynamically linked libraries Single application fileMultiple files that are loaded dynamically Before loadingAfter loading

4. Mobiiliohjelmointi Kevät 2009 4 Release Definition with DLLs First action to take in the beginning of the development of a new (or enhanced) systemFirst action to take in the beginning of the development of a new (or enhanced) system Defines all the necessary elements for a complete systemDefines all the necessary elements for a complete system Enables early toolchain development as well as decomposition of the system into different subsystemsEnables 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)Some parts can be left open for future extensions (plugins)

5. Mobiiliohjelmointi Kevät 2009 5 Required Implementation Facilities Dynamic capabilities for …Dynamic capabilities for … –Loading –Unloading –Selection if several possibilities exist Copy in processes’ own memory vs. in-place executionCopy in processes’ own memory vs. in-place execution –Data must be instantiated in any case RestrictionsRestrictions –All code should not be active all the time; memory related problems (e.g. fragmentation) if numerous loading of libraries of different sizes

6. Mobiiliohjelmointi Kevät 2009 6 Static and Dynamic DLLs Static DLLStatic DLL –(Commonly) Instantiated at application startup –Resides in the memory until the application terminates Dynamic DLL (often referred to as a plugin)Dynamic DLL (often referred to as a plugin) –Loaded and unloaded whenever needed –E.g. different plugin for different messaging types (email/SMS/MMS)

7. Mobiiliohjelmointi Kevät 2009 7 Challenges Fragmentation of the system into an unmanageable collection of DLLsFragmentation 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?Benefits of application-specific DLLs? Interface compatibility when market requirements force to change hardware characteristicsInterface compatibility when market requirements force to change hardware characteristics –Platform continuity by freezing the interface for some period of time

8. Mobiiliohjelmointi Kevät 2009 8 Content and goals OverviewOverview Implementation techniquesImplementation techniques PluginsPlugins Managing memory consumptionManaging memory consumption Using DLLsUsing DLLs Mobile Java implementationMobile Java implementation Symbian OS implementationSymbian OS implementation –DLL structure –ECOM SummarySummary

9. Mobiiliohjelmointi Kevät 2009 9 Implementing DLLs DLL External interface Code

10. Mobiiliohjelmointi Kevät 2009 10 Option 1: Offset based Calls DLL (support for plugins)APP LIBOrdinal Code

11. Mobiiliohjelmointi Kevät 2009 11 Option 2: Using Method Signatures DLL External interface Code methodX() methodY(int i, j) methodZ(string myName)

12. Mobiiliohjelmointi Kevät 2009 12 Comparison Offset based linking isOffset 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 isSignature based linking is –more natural (one can call methods from different libraries with ease) –more memory hungry (signatures must be saved somewhere)

13. Mobiiliohjelmointi Kevät 2009 13 Content and goals 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 –DLL structure –ECOM SummarySummary

14. 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

15. Mobiiliohjelmointi Kevät 2009 15 Abstract Factory as Implementation mechanism > AbsDLLA Client > AbsDLLB > AbsFactory ConcFactory1 ConcFactory2 CreateProductA CreateProductB CreateDLLA CreateDLLB CreateDLLA CreateDLLB ConcDLLA1ConcDLLA2ConcDLLB1ConcDLLB2 operAx operAy operBx operBy

16. Mobiiliohjelmointi Kevät 2009 16 Infrastructure and implementation level concerns Loading and unloading frameworkLoading and unloading framework ResolutionResolution –Searching and selecting the right plugin Policy for registering and removing of plugins to enable dynamic creation of new (or improved) featuresPolicy 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-effectsPlugin use can also introduce side-effects –E.g. Response to a message

17. Mobiiliohjelmointi Kevät 2009 17 Content and goals 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 –DLL structure –ECOM SummarySummary

18. 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!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 estimateDesk exercise to get the first estimate Running real code as soon as possible to get more realistic figures on actual performanceRunning real code as soon as possible to get more realistic figures on actual performance

19. Mobiiliohjelmointi Kevät 2009 19 Merging software and data elements as the last resort Merging packages and DLLsMerging packages and DLLs –Reduces overhead of referring to the methods of the packages/DLLs Flattening hierarchiesFlattening hierarchies –Reduces the number of identifiers, reduces the number of virtual function tables Embedding objectsEmbedding objects –Alters the layout of the data structure

20. Mobiiliohjelmointi Kevät 2009 20 Example: Embedded Pointers next object ref next object ref next object ref object next object next object next

21. Mobiiliohjelmointi Kevät 2009 21 Content and goals 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 –DLL structure –ECOM SummarySummary

22. Mobiiliohjelmointi Kevät 2009 22 Rules of Thumb for DLL Creation Shareable componentShareable component Variation or management pointVariation or management point –Several different implementations (or alternatives) Test process requirementsTest process requirements –Testing needs a concrete subject –Automated testing with binary deliveries End product of an organizational unitEnd 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

23. Mobiiliohjelmointi Kevät 2009 23 Content and goals 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 –DLL structure –ECOM SummarySummary

24. Mobiiliohjelmointi Kevät 2009 24 Mobile Java and DLLs All class files can be considered as more or less similar to DLLsAll class files can be considered as more or less 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 -> Smaller classes have certain advantages –Class memory overhead -> Larger classes have certain advantages No support for plugins due to CLDC restrictionsNo support for plugins due to CLDC restrictions –More capable mobile systems can include also support for plugins; not a technical impossibility in mobile setting

25. 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):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%

26. Mobiiliohjelmointi Kevät 2009 26 Effect of compression and different application structures Format14 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

27. Mobiiliohjelmointi Kevät 2009 27 Effect of compression and library structures FormatSize (bytes) Classes111694 JAR 76517 Pack 43233 Pack.gz 23791 tar.gz 46099 JXE104919

28. Mobiiliohjelmointi Kevät 2009 28 Library Considerations Prelinking of most commonly used standard librariesPrelinking 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 considerationsStructure considerations –JARring class by class cannot benefit from recurring constructs (e.g. constructors in every class)

29. Mobiiliohjelmointi Kevät 2009 29 Also programmer actions matter! public void push(Object e) { ensureCapasity(); // Check slots count ensureCapasity(); // Check slots count elements[size++] = e; elements[size++] = e;} public Object pop() { if (size == 0) throw new EmptyStackException(); if (size == 0) throw new EmptyStackException(); return elements[--size]; return elements[--size];} Ok?Ok?

30. Mobiiliohjelmointi Kevät 2009 30 Stack size Objects stored in Stack Object stack

31. Mobiiliohjelmointi Kevät 2009 31 Stack/Vector size Objects stored in Stack Objects stored in Vector but not in Stack Leaking Abstraction

32. Mobiiliohjelmointi Kevät 2009 32 Upgrade 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;}

33. Mobiiliohjelmointi Kevät 2009 33 Rules of Thumb for Mobile Java Avoid small classesAvoid small classes Avoid dependenciesAvoid dependencies Select size when relevant and manage vector/string usageSelect size when relevant and manage vector/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

34. 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)); } }

35. Mobiiliohjelmointi Kevät 2009 35 Results ArrayImp (minimal overhead)ArrayImp (minimal overhead) –Bytes: 8016 –Objects: 1 VectorImp (integers wrapped to objects)VectorImp (integers wrapped to objects) –Bytes: 40000 –Objects: 2002 VectorImpSimple (failures in guessing the size)VectorImpSimple (failures in guessing the size) –Bytes: 52000 –Objects: 2010 [Hartikainen: Java application and library memory consumption, TUT, 2005]

36. Mobiiliohjelmointi Kevät 2009 36 Example 2 static final int AMOUNT = 100; 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() { 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();}

37. Mobiiliohjelmointi Kevät 2009 37 Results UseString (simplest)UseString (simplest) –Bytes: 39000 –Objects: 450 UseStringBuffer (optimized)UseStringBuffer (optimized) –Bytes: 304 –Objects: 5 [Hartikainen: Java application and library memory consumption, TUT, 2005]

38. 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 behaviorA 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]

39. Mobiiliohjelmointi Kevät 2009 39 Content and goals 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 –DLL structure –ECOM SummarySummary

40. Mobiiliohjelmointi Kevät 2009 40 Offset-based linking DLL (support for plugins)APP LIBOrdinal Code

41. Mobiiliohjelmointi Kevät 2009 41 Expressed in Code with Macros (IMPORT_C, EXPORT_C) class CQAEng : public CBase {public: IMPORT_C static CQAEng* NewL(); IMPORT_C static CQAEng* NewL();........protected: CQAEng(); CQAEng();........}; 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() { iQuestion = 0; iQuestion = 0; iAnswer = 0; iAnswer = 0; iUsed = EFalse; iUsed = EFalse; }

42. Mobiiliohjelmointi Kevät 2009 42 Managing Binary Compatibility AbsoluteAbsolute –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-proofFuture-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

43. Mobiiliohjelmointi Kevät 2009 43 Programmer 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 versaPointers can be substituted with references and vice versa Names of exported non-virtual functions can be modifiedNames of exported non-virtual functions can be modified Input can be widened and output can be narrowedInput can be widened and output can be narrowed Specifier const can be appliedSpecifier const can be applied

44. Mobiiliohjelmointi Kevät 2009 44 Content and goals 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 –DLL structure –ECOM SummarySummary

45. Mobiiliohjelmointi Kevät 2009 45 ECOM Framework Interface client Interface (CCryptoIF) Implementation (CCryptoSW) NewL ECOM Framework REComSession::CreateImplementationL Implements Resolves and instantiates

46. Mobiiliohjelmointi Kevät 2009 46 ECOM Interface Requirements Abstract class with a set of one or more pure virtual functionsAbstract 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 objectProvides 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,...)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 purposesTUid data member, which is used internally to identify an implementation instance for cleanup purposes

47. Mobiiliohjelmointi Kevät 2009 47 Content and goals 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 –DLL structure –ECOM SummarySummary

48. Mobiiliohjelmointi Kevät 2009 48 Summary Dynamically linked libraries offer a way to save memory, as code can be shared by several unitsDynamically 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)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)Linking can be based on e.g. method signatures (Java) or offset (Symbian OS) Plugins are special DLLs that can be dynamically loaded and unloadedPlugins are special DLLs that can be dynamically loaded and unloaded –Common interface –Implementation for the interface –Framework for loading the interface