Dynamically Linked Libraries DLL. Juha JärvensivuJ

Transcription

1 Dynamically Linked Libraries DLL Juha JärvensivuJ

2 Content and goals Overview Implementation techniques Plugins Managing memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary

3 Motivation Several applications use the same code; ; no need to link it with all applications 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

4 Dynamically linked libraries Before loading After loading Single application file Multiple files that are loaded dynamically

5 Release Definition with DLLs Defines what files and auxiliaries are needed for performing compilation and installation for a complete system Several levels of release definitions Device Platform Application Enables decomposition of the system into different subsystems

6 Required Implementation Dynamic loading unloading Facilities 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

7 Static and Dynamic DLLs Static DLL (Commonly) Instantiated at application startup Resides in the memory until the application terminates Dynamic DLL (plugin) Loaded and unloaded whenever needed E.g. different plugin for different messaging types ( /sms/mms)

8 Challenges Fragmentation of the system into an unmanageable collection of DLLs Versioning Managing dependencies between libraries Application-specific DLLs Interface compatibility when market requirements force to change hardware characteristics Platform continuity by freezing the interface for some period of time

9 Content and goals Overview Implementation techniques Plugins Managing memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary

10 Implementing DLLs DLL Code External interface Code Code

11 Option 1: Off-set based linking APP DLL (support for plugins) Code LIB Ordinal Code Code

12 Option 2 Signature based linking DLL methodx() methody(int i, j) methodz(string myname) External interface Code Code Code

13 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)

14 Content and goals Overview Implementation techniques Plugins Managing DLL memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary

15 Plugin Principle No plugins loaded Plugin P2 loaded Plugin P2 unloaded and P1 loaded P1 Application Plugin interface P2 P3 Plugin implementations Application P2 P1 P3 Plugin implementations Application P1 P2 P3 Plugin implementations

16 Abstract Factory as Implementation mechanism Client <<interface>> AbsFactory <<interface>> AbsDLLA operax operay <<interface>> AbsDLLB operbx operby CreateProductA CreateProductB ConcDLLA1 ConcDLLA2 ConcDLLB1 ConcDLLB2 ConcFactory1 CreateDLLA CreateDLLB ConcFactory2 CreateDLLA CreateDLLB

17 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 effects E.g. Response to a message

18 Content and goals Overview Implementation techniques Plugins Managing DLL memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary

19 Principles 1. Use the simplest structure needed! 2. Make all DLLs (and DLL developers) responsible for the memory they allocate Needed for realistically defining a release in any case 3. When in doubt, consider what will eventually happen at the level of implementation

20 Interface design Select the right operation granularity Allow client to control transmissions Minimize the amount of data to be transmitted Especially important if thread/process interfaces are to be crossed Select the best way to transmit data (Lend, Borrow, Steal)

21 Lend Borrow Steal Client Get(d) Provider Client Get():d Rel(d) Provider Client Get():d Provider Set(d = 1) Set(d = 1) new(1) delete d:data d:data d:data Lend Borrow Steal

22 Merging Elements 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

23 Example: Embedded Pointers next object ref next object object next object ref next object object next object ref object next object

24 Content and goals Overview Implementation techniques Plugins Managing DLL memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary

25 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

26 Content and goals Overview Implementation techniques Plugins Managing DLL memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary

27 Mobile Java and DLLs All class files can be considered as more or less similar to DLLs Linking is a built-in 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

28 Average Class File Content (CLDC library classes) Metadata 45.4% (about half is debug info) Strings 34.8% Bytecode 19.1% Class field data 0.4% Instance field data 0.4%

29 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 loading becomes easier

30 Content and goals Overview Implementation techniques Plugins Managing DLL memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary

31 Offset-based linking APP DLL (support for plugins) Code LIB Ordinal Code Code

32 Expressed in Code with Macros (IMPORT_C, EXPORT_C) EXPORT_C CQAEng * CQAEng::NewL() class CQAEng : public CBase { { CQAEng* * self = public: new (ELeave( ELeave) CQAEng; IMPORT_C static CQAEng* NewL(); CleanupStack::PushL(self);... self->constructl ConstructL(); protected: CleanupStack::Pop(); CQAEng(); return self;... } }; CQAEng::CQAEng() { iquestion = 0; ianswer = 0; iused = EFalse; }

33 Expressed in Code with Macros (IMPORT_C, EXPORT_C) EXPORT_C CQAEng * CQAEng::NewL() class CQAEng : public CBase { { CQAEng* * self = public: new (ELeave( ELeave) CQAEng; IMPORT_C static CQAEng* NewL(); CleanupStack::PushL(self);... self->constructl ConstructL(); protected: CleanupStack::Pop(); CQAEng(); return self;... } }; CQAEng::CQAEng() { iquestion = 0; ianswer = 0; iused = EFalse; }

34 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

35 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

36 Content and goals Overview Implementation techniques Plugins Managing DLL memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary

37 ECOM Framework Symbian OS implementation for plugin components From version 8.0

38 ECOM Framework Interface client NewL Interface (CCryptoIF) REComSession::CreateImplementationL Implements ECOM Framework Implementation (CCryptoSW) Implementation (CCryptoSW) Resolves and instantiates

39 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

40 Content and goals Overview Implementation techniques Plugins Managing DLL memory consumption Using DLLs Mobile Java implementation Symbian OS implementation DLL structure ECOM Summary

41 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