1. Mobiiliohjelmointi Kevät 2009 1 2. Memory Management Basics of memory usage in mobile devicesBasics of memory usage in mobile devices –Static and dynamic allocation –Managing memory organization Memory management in Symbian OSMemory management in Symbian OS Memory management in Mobile JavaMemory management in Mobile Java SummarySummary

2. Mobiiliohjelmointi Kevät 2009 2 Rationale Memory usage is a tangling concern in mobile devicesMemory usage is a tangling concern in mobile devices –All programs use memory –In order to reduce costs, only limited amount of memory available in mobile devices –Also power consumption factor exists Memory usage is to a great extent determined by programmers, although used tools also have an effectMemory usage is to a great extent determined by programmers, although used tools also have an effect –The fashion programs are composed is an issue –Allocation of variables to memory is an issue Not an option to blame infrastructure but focus placed on application designNot an option to blame infrastructure but focus placed on application design

3. Mobiiliohjelmointi Kevät 2009 3 Dynamic allocation Execution stackExecution stack –Manages control flow of a thread, allocation takes places automatically as execution advances –Contains activation records (or stack frames); one per method/function call HeapHeap –Unstructured pool of memory –Must be managed by the programmer in C++; Java VM manages this automatically –Risk of garbaging; risk of fragmentation (Disk)(Disk)

4. Mobiiliohjelmointi Kevät 2009 4 int todo { return 1; }; int main() { todo(); } main() todo() stack Memory todomain source code return address Program and Stack Program image

5. Mobiiliohjelmointi Kevät 2009 5 Stack and Activation Record Previous activation record Next activation record Return address Return value Parameters Local variables Other information Activation record

6. Mobiiliohjelmointi Kevät 2009 6 Example struct Sample { int i; int i; char c; char c;}; How to allocate to different memory locations? How to allocate to different memory locations? Does it really matter? Does it really matter?

7. Mobiiliohjelmointi Kevät 2009 7 Sample in Memory int SInStack() { Sample s;.... } int SInHeap() { Sample * s; s = new Sample;.... } s.i s.c... s s.i s.c... Stack Heap Stack How about limited stack size?

8. Mobiiliohjelmointi Kevät 2009 8 Content and goals Basics of memory usage in mobile devicesBasics of memory usage in mobile devices –Static and dynamic allocation –Managing memory organization Memory management in Symbian OSMemory management in Symbian OS Memory management in Mobile JavaMemory management in Mobile Java SummarySummary

9. Mobiiliohjelmointi Kevät 2009 9 Static allocation Simplest case (in practice usually allocated in heap, but without programmer interventions)Simplest case (in practice usually allocated in heap, but without programmer interventions) Variable is statically allocated to a certain location in the memoryVariable is statically allocated to a certain location in the memory int x; int x; int * pointer_to_static() int * pointer_to_static() { static int y; static int y; return & y; return & y; } Restrictions regarding e.g. information hiding, etc.Restrictions regarding e.g. information hiding, etc.

10. Mobiiliohjelmointi Kevät 2009 10 Stack Home for transient objectsHome for transient objects –Allocation and deallocation is automatic –No need to make an explicit operating system call for memory References and sharing of data problematicReferences and sharing of data problematic int * pointer_to_int() int * pointer_to_int() { int y; int y; return & y; return & y; }

11. Mobiiliohjelmointi Kevät 2009 11 Example x pointer_to_int activation... Calling activation x... Calling activation Running pointer_to_int After executing pointer_to_int stack pointer Reference to x f... Calling activation Running other procedure stack pointer Some other activation...

12. Mobiiliohjelmointi Kevät 2009 12 Heap Home for long-living objectsHome for long-living objects –Sharing is less problematic than with stack-based variables, but errors can still occur (aliasing -> copy-on-write?) –Large or global objects/data/variables that are needed in all phases of the program Reference passing commonly advocated in mobile settingReference passing commonly advocated in mobile setting Management of creation and deletion requiredManagement of creation and deletion required int * pointer_to_int() int * pointer_to_int() { return new int(0); return new int(0); }

13. Mobiiliohjelmointi Kevät 2009 13 Example x... x Copy of x... Activation 1 &x... &x... &x... Full object in stack Reference in stack Activation 2

14. Mobiiliohjelmointi Kevät 2009 14 Inheritance and virtual machine Inheritance implies a data structure for maintaining information needed for dynamic bindingInheritance implies a data structure for maintaining information needed for dynamic binding –Virtual function table Virtual machine introduces yet another infrastructure on top of a processorVirtual machine introduces yet another infrastructure on top of a processor –Class loader loads programs –Execution engine acts as the scheduler, memory manager, and interpreter –Run-time data

15. Mobiiliohjelmointi Kevät 2009 15 Virtual Function Table class C { int i; char c; virtual void v(); virtual double d(); }; i c ID Stack/Heap (Object instantiated in memory) d-id Virtual function table (program memory, RAM) v-id C.v code C.d code Method code (program memory, RAM)

16. Mobiiliohjelmointi Kevät 2009 16 Memory Allocation: What Is Allocated Where? ConstantsConstants –ROM if enabled Program binariesProgram binaries –ROM (in-place execution; how about e.g. code encryption for protection or upgrades?) –RAM (additional RAM required for programs) DataData –RAM –Saving to disk/flash memory? What would the user be expecting?

17. Mobiiliohjelmointi Kevät 2009 17 Content and goals Basics of memory usage in mobile devicesBasics of memory usage in mobile devices –Static and dynamic allocation –Managing memory organization Memory management in Symbian OSMemory management in Symbian OS Memory management in Mobile JavaMemory management in Mobile Java SummarySummary

18. Mobiiliohjelmointi Kevät 2009 18 Managing memory organization Principle:Principle: –Use the simplest data structure that offers the necessary operations Then:Then: –Consider linear data structures instead of distribution (less system calls, design-time management, monitoring option, cache, index size) –Consider other means of benefitting from memory layout (some basic principles to follow) –Consider packing

19. Mobiiliohjelmointi Kevät 2009 19 Non-linear and linear data structure Program’s address space List-based data structureLinear data structure Cache window

20. Mobiiliohjelmointi Kevät 2009 20 Basic Principles Allocate all memory at the beginning of a programAllocate all memory at the beginning of a program Allocate memory for several items even if you only need oneAllocate memory for several items even if you only need one Use standard allocation sizesUse standard allocation sizes Reuse objectsReuse objects Release early, allocate lateRelease early, allocate late Use permanent storage or ROM when applicableUse permanent storage or ROM when applicable Avoid recursion (of uncontrolled depth?)Avoid recursion (of uncontrolled depth?)

21. Mobiiliohjelmointi Kevät 2009 21 Consider packing Use compression with careUse compression with care Use efficient resource storage formatUse efficient resource storage format Consider word alignmentConsider word alignment struct S { struct S { char b; // boolean char b; // boolean char b; // boolean char b; // boolean int i; char c; int i; char c; char c; int i; char c; int i; } }

22. Mobiiliohjelmointi Kevät 2009 22 Packing

23. Mobiiliohjelmointi Kevät 2009 23 Content and goals Basics of memory usage in mobile devicesBasics of memory usage in mobile devices –Static and dynamic allocation –Managing memory organization Memory management in Symbian OSMemory management in Symbian OS Memory management in Mobile JavaMemory management in Mobile Java SummarySummary

24. Mobiiliohjelmointi Kevät 2009 24 Naming Conventions Class names start with CClass names start with C Kernel class names start with DKernel class names start with D Type names start with TType names start with T Mixin class names start with MMixin class names start with M Enumerated class names start with EEnumerated class names start with E Resource names start with RResource names start with R Method names start with a capital letterMethod names start with a capital letter Names of methods that can throw an exception end with L (or LC)Names of methods that can throw an exception end with L (or LC) Simple getters and setters reflect the name of the variableSimple getters and setters reflect the name of the variable Instance variable names begin with iInstance variable names begin with i Argument names begin with aArgument names begin with a Constant names begin with KConstant names begin with K Automatic variable names begin with lower-case lettersAutomatic variable names begin with lower-case letters

25. Mobiiliohjelmointi Kevät 2009 25 Descriptors Symbian way of using stringsSymbian way of using strings _L("Hello"); (depreciated except in demos and debugging) _L("Hello"); (depreciated except in demos and debugging) _LIT(KHelloRom, "Hello"); _LIT(KHelloRom, "Hello"); // String in program binary. // String in program binary. TBufC HelloStack(KHelloRom); // Data in thread stack. TBufC HelloStack(KHelloRom); // Data in thread stack. HBufC* helloHeap = KHelloRom.AllocLC(); // Data in heap. HBufC* helloHeap = KHelloRom.AllocLC(); // Data in heap. Guards against overflowsGuards against overflows char userid[8]; // Vanilla C++ strcpy(userid, "santa.claus@northpole.org"); TBuf userid; // Symbian userid = _L("santa.claus@northpole.org");

26. Mobiiliohjelmointi Kevät 2009 26 Some memory layouts iLength 12 iPtr Hello, World! iLength 12 iMaxLength 12 iPtr (unmodifiable) TPtrC (modifiable) TPtr ROM, heap or stack (unmodifiable) TBufC iLength 12 iBuf Hello, world! (Modifiable) TBuf iLength 12 iMaxLength 15 iBuf Hello, world TDesC TBufC TDesC TDes TPtr TDesC TDes TBuf TDesC TPtrC

27. Mobiiliohjelmointi Kevät 2009 27 Using Descriptors Use descriptors rather than degenerate to Ttext* formatUse descriptors rather than degenerate to Ttext* format Use TDesC& for argumentsUse TDesC& for arguments –Light-weight –Safe (no accidential modifiction) –Any descriptor can be passed Use new only with HBufCUse new only with HBufC –Reserve others from stack Type casting is possibleType casting is possible –HBufC::Des –TPtr, TDesC::Alloc –HBufC *

28. Mobiiliohjelmointi Kevät 2009 28 Exceptions Trap harness rather than standard exceptionsTrap harness rather than standard exceptions TRAPD(error, BehaveL()); // try if (error != KErrNone) // Exception handler { // catch { // catch if (error == KErrNotSupported) {...} if (error == KErrNotSupported) {...} if (error == KErrUnknown) {...} if (error == KErrUnknown) {...} } User::Leave(KOutOfMemory); // throw

29. Mobiiliohjelmointi Kevät 2009 29 Exceptions and Allocation All memory allocations use an overridden version of new operatorAll memory allocations use an overridden version of new operator c = new (ELeave) CMyClass(); Corresponding methodCorresponding method c = new CMyClass(); if (!c) User::Leave(KOutOfMemory); return c;

30. Mobiiliohjelmointi Kevät 2009 30 Problem: What happens to automatic heap-based variables in an exception? Stack Heap Before an exception Stack Heap Memory garbaging after an exception

31. Mobiiliohjelmointi Kevät 2009 31 Cleanup Stack – An Auxiliary Data Structure Stack Heap Cleanup Stack Cleanup stack enables deallocation during an exception

32. Mobiiliohjelmointi Kevät 2009 32 Using Cleanup Stack A programmer responsiblityA programmer responsiblity Only for automatic variables, never for othersOnly for automatic variables, never for others CMyClass * c = new CMyClass(); CleanupStack::PushL(c)... c is used CleanupStack::Pop(); // c delete c; c = 0; Classes derived from CBase get their destructor called, for others only memory is deallocatedClasses derived from CBase get their destructor called, for others only memory is deallocated Also other actions (e.g. CleanupStack::ClosePushL(file);)Also other actions (e.g. CleanupStack::ClosePushL(file);)

33. Mobiiliohjelmointi Kevät 2009 33 Two-Phase Construction Cleanup stack cannot help in the creation of objectsCleanup stack cannot help in the creation of objects Therefore:Therefore: –actual constructor should never fail, and –problematic aspects should be executed only after a reference to the object has been pushed to the cleanup stack CData * id = new (ELeave) CData(256); CleanupStack::PushL(id);id->ConstructL();

34. Mobiiliohjelmointi Kevät 2009 34 Shorthands CItem::NewL() { CItem * self = new (ELeave) CItem; CItem * self = new (ELeave) CItem; CleanupStack::PushL(self); CleanupStack::PushL(self); self->ConstructL(); self->ConstructL(); CleanupStack::Pop(); // self CleanupStack::Pop(); // self return self; return self;} CItem::NewLC() { CItem * self = new (ELeave) CItem; CItem * self = new (ELeave) CItem; CleanupStack::PushL(self); CleanupStack::PushL(self); self->ConstructL(); self->ConstructL(); return self; }

35. Mobiiliohjelmointi Kevät 2009 35 Content and goals Basics of memory usage in mobile devicesBasics of memory usage in mobile devices –Static and dynamic allocation –Managing memory organization Memory management in Symbian OSMemory management in Symbian OS Memory management in Mobile JavaMemory management in Mobile Java SummarySummary

36. Mobiiliohjelmointi Kevät 2009 36 Motivation 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?

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

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

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

40. Mobiiliohjelmointi Kevät 2009 40 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

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

42. Mobiiliohjelmointi Kevät 2009 42 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]

43. Mobiiliohjelmointi Kevät 2009 43 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();}

44. Mobiiliohjelmointi Kevät 2009 44 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]

45. Mobiiliohjelmointi Kevät 2009 45 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]

46. Mobiiliohjelmointi Kevät 2009 46 Content and goals Basics of memory usage in mobile devicesBasics of memory usage in mobile devices –Static and dynamic allocation –Managing memory organization Memory management in Symbian OSMemory management in Symbian OS Memory management in Mobile JavaMemory management in Mobile Java SummarySummary

47. Mobiiliohjelmointi Kevät 2009 47 Summary Memory related considerations are a practical necessityMemory related considerations are a practical necessity –Even virtual machines require programmer to consider allocation of variables and the use of data structures Design idioms and patterns have been introduced that give general guidelinesDesign idioms and patterns have been introduced that give general guidelines –Preallocation and static allocation simplify memory management –Linear data structures offer several benefits –Data packing as the last resort Mobile development platforms generally assume that the developers are aware of the most common pitfallsMobile development platforms generally assume that the developers are aware of the most common pitfalls –Often not adequately documented but must be experimented in practice!