4. Dynamic Linking. Summary. DLL structure ECOM

Transcription

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

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 2

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

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

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 5

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 ( /sms/mms) 6

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 7

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

9 Implementing DLLs DLL Code External interface Code Code 9

10 Option 1: Offset based Calls APP DLL (support for plugins) Code LIB Ordinal Code Code 10

11 Option 2: Using Method Signatures DLL methodx() methody(int i, j) methodz(string myname) External interface Code Code Code 11

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

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

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

15 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 15

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 16

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

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 18

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 19

20 Example: Embedded Pointers next object ref next object object next object ref next object object next object ref object next object 20

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

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 22

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

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 24

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% 25

26 Effect of compression and different application structures Format 14 classes 1 class No compression No compression, obfuscated JAR Jar Obfuscated Pack Pack.gz

27 Effect of compression and library structures Format Size (bytes) Classes JAR Pack Pack.gz tar.gz JXE

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

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? 29

30 Object stack size Stack Objects stored in Stack 30

31 Leaking Abstraction Objects stored in Vector but not in Stack size Stack/Vector Objects stored in Stack 31

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

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 33

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

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

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(); } 36

37 Results UseString (simplest) Bytes: Objects: 450 UseStringBuffer (optimized) Bytes: 304 Objects: 5 [Hartikainen: Java application and library memory consumption, TUT, 2005] 37

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: class: 7467 [Hartikainen: Java application and library memory consumption, TUT, 2005] 38

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

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

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; } 41

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 42

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 43

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

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

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 46

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

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 48