1 / 48

4. Dynamic Linking

4. Dynamic Linking. Overview Implementation techniques Plugins Managing memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary. Motivation.

wynn
Download Presentation

4. Dynamic Linking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 4. Dynamic Linking • Overview • Implementation techniques • Plugins • Managing memory consumption • Using DLLs • Mobile Java implementation • Symbian OS implementation • DLL structure • ECOM • Summary MobiiliohjelmointiKevä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 MobiiliohjelmointiKevät 2009

  3. Dynamically linked libraries Before loading After loading Single application file Multiple files that are loaded dynamically MobiiliohjelmointiKevä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) MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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) MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevät 2009

  9. Implementing DLLs DLL Code Externalinterface Code Code MobiiliohjelmointiKevät 2009

  10. Option 1: Offset based Calls APP DLL (support for plugins) Code LIB Ordinal Code Code MobiiliohjelmointiKevät 2009

  11. Option 2: Using Method Signatures DLL Code methodX() methodY(int i, j) methodZ(string myName) Externalinterface Code Code MobiiliohjelmointiKevä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) MobiiliohjelmointiKevä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 MobiiliohjelmointiKevät 2009

  14. Plugin Principle No pluginsloaded Plugin P2loaded Plugin P2 unloadedand P1 loaded Application Application Application Plugininterface P2 P1 P2 P2 P1 P1 P3 P3 P3 Plugin implementations Plugin implementations Plugin implementations MobiiliohjelmointiKevät 2009

  15. Abstract Factory as Implementation mechanism <<interface>> AbsDLLB <<interface>> AbsDLLA Client operAx operAy operBx operBy <<interface>> AbsFactory CreateProductA CreateProductB ConcDLLA1 ConcDLLA2 ConcDLLB1 ConcDLLB2 ConcFactory2 ConcFactory1 CreateDLLA CreateDLLB CreateDLLA CreateDLLB MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevät 2009

  18. Principles • Always use the simplest structure you really need! • 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! • 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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevät 2009

  20. Example: Embedded Pointers next objectref object next object next objectref object next object next objectref object next object MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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% MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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) MobiiliohjelmointiKevä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? MobiiliohjelmointiKevät 2009

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

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

  32. Upgrade public Object pop() { if (size == 0) throw new EmptyStackException(); Object result = elements[--size]; elements[size] = null; return result; } MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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)); } } MobiiliohjelmointiKevä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] MobiiliohjelmointiKevä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(); } MobiiliohjelmointiKevä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] MobiiliohjelmointiKevä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] MobiiliohjelmointiKevä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 MobiiliohjelmointiKevät 2009

  40. Offset-based linking APP DLL (support for plugins) Code LIB Ordinal Code Code MobiiliohjelmointiKevä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; } MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevät 2009

  45. ECOM Framework REComSession::CreateImplementationL NewL Interfaceclient Interface(CCryptoIF) ECOMFramework Implements Implementation(CCryptoSW) Implementation(CCryptoSW) Resolves andinstantiates MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevä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 MobiiliohjelmointiKevät 2009

More Related