1. Windows Memory Management, Memory- Mapped Files, and DLLs

2. – 2 – OBJECTIVES (1 of 2) Upon completion of this Chapter you will be able to: Describe the Windows memory management architecture and the role of heaps and memory-mapped files Use multiple independent heaps in applications requiring dynamic memory management Use Structured Exception Handling to respond to memory allocation errors Use memory-mapped files

3. – 3 – OBJECTIVES (2 of 2) Determine when to use the independent heaps and when to use memory-mapped files and to describe the advantages and disadvantages of each Describe Windows dynamic link libraries (DLLs) Describe the difference between static, implicit, and explicit linking Describe the advantages and disadvantages of each Use DLLs to load different implementations of the same function

4. – 4 – OVERVIEW (1 of 2)  32-bit operating system, so pointers are 4-byte objects  Win64 provides 64-bit pointers  Processes have a private 4GB virtual address space  Half (2GB) is available to a process  Remainder allocated to shared data and code  Win64 enlarges VA space; required for many applications  Programs can create independent memory “heaps” Processes can map files to memory  Processes can share memory through a mapped file  Fast and convenient for some file processing

5. – 5 – OVERVIEW (2 of 2)  Dynamic Link Libraries with Monolithic Programs Gather all the source code, including commonly used Chapters such as utility functions Put all the source code in a single project Build, test, debug, and use the program Inefficiency Recompile same code in all projects All executables include the same object code Waste of disc space and physical memory at run time Maintenance complexity as shared code changes

6. Part I Memory Management and Heaps

7. – 7 – Windows Program Heap API: HeapCreate, HeapDestroy, HeapAlloc, HeapFree MMF API: CreateFileMapping, CreateViewOfFile Virtual Memory API Windows Kernel with Virtual Memory Manager Physical Memory Disc & File System C library: malloc, free Memory Management Architecture

8. – 8 – HEAPS (1 of 2)  Pools of memory within the process virtual address space  Every process has a default process heap  A process may have more than one heap. Benefits of separate heaps include:  Fairness (between threads and between uses)  Allocation efficiency (fixed size blocks in each heap)  Deallocation efficiency (you can deallocate a complete data structure with one call)  Locality of reference efficiency

9. – 9 – HEAPS (2 of 2)  Every process has a process heap  Every heap has a handle  The programmer can use the process heap or create new ones  HANDLE GetProcessHeap (VOID)  Return: The handle for the process’ heap; NULL on failure

10. – 10 – Node Record Not allocated Process Heap RecHeap NodeHeap Virtual Address Space Program ProcHeap = GetProcessHeap ( ); pRoot = HeapAlloc (ProcHeap); RecHeap = HeapCreate ( ); NodeHeap = HeapCreate ( ); while ( ) { pRec = HeapAlloc (RecHeap); pNode = HeapAlloc (NodeHeap); · · · } HeapFree (RecHeap, 0, pRec); HeapFree (NodeHeap, 0, pNode); HeapDestroy (RecHeap); HeapDestroy (NodeHeap); · · · MEMORY MGT. IN MULTIPLE HEAPS

11. – 11 – HEAP MANAGEMENT (1 of 2)  HANDLE HeapCreate (DWORD flOptions, DWORD dwInitialSize, DWORD dwMaximumSize)  Return: A heap handle or NULL on failure  dwMaximumSize — How large the heap can become 0 — “growable heap”; no fixed limit non-zero — “non-growable heap” The entire block is allocated from the virtual address space But only the initial size is committed in the paging file

12. – 12 – HEAP MANAGEMENT (2 of 2)  flOptions is a combination of two flags: HEAP_GENERATE_EXCEPTIONS HEAP_NO_SERIALIZE  By generating exceptions, you can avoid explicit tests after each heap management call

13. – 13 – HEAPS  BOOL HeapDestroy (HANDLE hHeap) hHeap — a heap generated using HeapCreate Do not destroy the process’ heap (obtained using GetProcessHeap ) Benefits of HeapDestroy : No data structure traversal code No need to deallocate each individual data structure element, which can be time-consuming

14. – 14 – MANAGING HEAP MEMORY (1 of 4)  LPVOID HeapAlloc (HANDLE hHeap, DWORD dwFlags, DWORD dwBytes)  Return: A pointer to the allocated memory block (of size dwBytes ) or NULL on failure (unless exception generation is specified)  hHeap — Handle from GetProcessHeap or HeapCreate  dwFlags — A combination of: HEAP_GENERATE_EXCEPTIONS HEAP_NO_SERIALIZE HEAP_ZERO_MEMORY — Allocated memory initialized to zero

15. – 15 – MANAGING HEAP MEMORY (2 of 4)  BOOL HeapFree (HANDLE hHeap, DWORD dwFlags,  LPVOID lpMem)  dwFlags — Should be zero (or HEAP_NO_SERIALIZE )  lpMem — Should have a value returned by HeapAlloc or HeapReAlloc  hHeap — Should be the heap that lpMem was allocated from

16. – 16 – MANAGING HEAP MEMORY (3 of 4)  LPVOID HeapReAlloc (HANDLE hHeap, DWORD dwFlags,  LPVOID lpMem, DWORD dwBytes)  Return: Pointer to the reallocated block. Failure returns NULL or causes exception.  dwFlags — Some essential control options: HEAP_GENERATE_EXCEPTIONS and HEAP_NO_SERIALIZE HEAP_ZERO_MEMORY — Only newly allocated memory is initialized HEAP_REALLOC_IN_PLACE_ONLY — Do not move the block  lpMem — Existing block in hHeap to be reallocated  dwByte — New block size

17. – 17 – MANAGING HEAP MEMORY (4 of 4)  DWORD HeapSize (HANDLE hHeap, DWORD dwFlags,  LPVOID lpMem)  Return: The size of the block or zero on failure.

18. – 18 – HEAP FLAGS (1 of 2)  HEAP_NO_SERIALIZE Specified in HeapCreate, HeapAlloc, and other functions Performance gain (about 15% in tests) as functions do not provide mutual exclusion to threads accessing the heap Can safely be used if (BUT, BE CAREFUL): Your process uses only a single thread Each thread has its own heap(s) that no other thread can access You provide your own mutual exclusion mechanism to prevent concurrent access to a heap by several threads You use HeapLock and HeapUnlock

19. – 19 – HEAP FLAGS (2 of 2)  HEAP_GENERATE_EXCEPTIONS Allows you to avoid error tests after each allocation

20. – 20 – OTHER HEAP FUNCTIONS  HeapValidate Determine whether a heap has been corrupted  HeapCompact Combine adjacent free blocks; decommit large free blocks  HeapWalk Determine all blocks allocated within a heap

21. – 21 – EXAMPLE-A  Write a program, sortHP, which reads fixed-size records from a file into a memory-allocated buffer in a heap, where the first 8 characters are a birth date (CCYYMMDD format). The rest of the record is a line of text. Enter each date in an array, along with a file position. Each array element will contain the date and the file position of the record (which is not fixed length). Sort the array using the C library qsort function. Print out the complete file sorted by birth date. Repeat the process for each file on the command line. Before each new file, destroy the heaps from the preceding file.

22. – 22 – EXAMPLE-A  The TestData directory contains two text files with 64- byte records that can be used to test your program. Or, use the RandFile program to generate sortable files of any size.

23. – 23 – EXAMPLE-A  Modify the sort program to create sortBT, which enters the records in to a binary search tree and then scans the tree to display the records in order. Allocate the tree nodes and the data in separate heaps. Destroy the heaps before sorting the next file, rather than freeing individual tree nodes and data elements. Test the program with and without heap serialization and determine whether there is a detectable performance difference.

24. Part II Memory-Mapped Files

25. – 25 – MEMORY-MAPPED FILES  Advantages to mapping your virtual memory space directly to normal files rather than the paging file: You never need to perform direct file I/O Data structures you create are saved in the file You can use in-memory algorithms (string processing, sorts, search trees) to process data even though the file may be much larger than available physical memory There is no need to manage buffers and the file data they contain Multiple processes can share memory (this is the only way), and the file views will be coherent There is no need to consume space in the paging file

26. – 26 – PROCESS ADDRESS SPACE MAPPED TO A FILE Program fH = CreateFile ( ); mH = CreateFileMapping (fH); while ( ) { pRecA = MapViewOfFile (mH); pRecB = MapViewOfFile (mH); pRecB -> Data = pRecA -> Data; · · · UnmapViewOfFile (pRecA); UnmapViewOfFile (pRecB); } CloseHandle (mH); CloseHandle (fH); · · · Process Address Space File

27. – 27 – FILE-MAPPING OBJECTS (1 of 4)  HANDLE CreateFileMapping (HANDLE hFile,  LPSECURITY_ATTRIBUTES lpsa,  DWORD dwProtect, DWORD dwMaximumSizeHigh,  DWORD dwMaximumSizeLow, LPCTSTR lpMapName)  Return: A file mapping handle or NULL

28. – 28 – FILE-MAPPING OBJECTS (2 of 4)  Parameters hFile — Open file handle; protection flags compatible with dwProtect LPSECURITY_ATTRIBUTES — NULL for now dwProtect — How you can access the mapped file: PAGE_READONLY — Pages in the mapped region are read only PAGE_READWRITE — Full access if hFile has both GENERIC_READ and GENERIC_WRITE access PAGE_WRITECOPY — When you change mapped memory, a copy is written to the paging file

29. – 29 – FILE-MAPPING OBJECTS (3 of 4) dwMaximumSizeHigh and dwMaximumSizeLow — Specify the size of the mapping object; 0 for current file size. The file is extended if the current file size is smaller than the map size. lpMapName — Names the mapping object, allowing other processes to share the object

30. – 30 – FILE-MAPPING OBJECTS (4 of 4)  You can also obtain a file-mapping handle by specifying an existing mapping object name  HANDLE OpenFileMapping (DWORD dwDesiredAccess,  BOOL bInheritHandle, LPCTSTR lpNameP)  Return: A file mapping handle or NULL  CloseHandle destroys mapping handles

31. – 31 – MAPPING PROCESS ADDRESS SPACE (1 of 3)  LPVOID MapViewOfFile (HANDLE hMapObject,  DWORD dwAccess, DWORD dwOffsetHigh,  DWORD dwOffsetLow, DWORD cbMap)  Return: The starting address of the block (file view) or NULL on failure  hMapObject — Identifies a file-mapping object  dwAccess — Must be compatible with mapping object’s access: FILE_MAP_WRITE FILE_MAP_READ FILE_MAP_ALL_ACCESS

32. – 32 – MAPPING PROCESS ADDRESS SPACE (2 of 3)  dwOffsetHigh and dwOffsetLow Starting location of the mapped file region Must be a multiple of 64K Zero offset to map from beginning of file  cbMap — Size in bytes of the mapped region Zero indicates entire file Note: The map size is limited by the 32-bit address

33. – 33 – MAPPING PROCESS ADDRESS SPACE (3 of 3)  MapViewOfFileEx is similar, but you can specify an existing address  BOOL UnmapViewOfFile (LPVOID lpBaseAddress) To release file views

34. – 34 – FILE-MAPPING LIMITATIONS Disparity between Windows’s 64-bit file system and 32-bit addressing With a large file (greater than 4GB) you cannot map everything into virtual memory space Process data space is limited to 2GB You cannot use all 2GB; available contiguous blocks will be smaller When dealing with large files, you must create code that carefully maps and unmaps file regions as you need them

35. – 35 – BASED POINTERS (1 of 2)  If you use pointers in a mapped file region, they should be of type _based A conventional pointer refers to the virtual address This address base will almost certainly be different the next time that file is mapped or a new view is created of the same region The pointer should be based on the view address

36. – 36 – BASED POINTERS (2 of 2)  int *pi;  int __based(pi) *bpi, i; ...  pi = MapViewOfFile (...);  *pi = 3;  bpi = pi;  i = *bpi; ...

37. – 37 – EXAMPLE-B  Rewrite the atou (ASCII to UNICODE) program to create atouMM Use memory mapping only; do not use ReadFile and WriteFile You do not need to change the main function in atou.c. Instead, change the asc2un.c function to create asc2unMM.c.

38. – 38 – EXAMPLE-B  Rewrite the sort program of the previous section to create sortMM, so that key records (in the array) are mapped to a “key” file Do not use the file pointers; instead, use based pointers to address in a view of the original file As part of the test of _based pointers, have a program option to simply use the saved key file to produce a sorted listing without actually performing a sort. The next slide shows diagrams the operation. This is a difficult exercise!

39. – 39 – sortMM OPERATION sortMM MyFile MyFile.idx K i : Key S i : String P i : Based Pointer KiKi PiPi KjKj PjPj KkKk PkPk ··· K0K0 S0S0 K1K1 S1S1 K2K2 S2S2 MyFile ··· K0K0 P0P0 K1K1 P1P1 K2K2 P2P2 qsort

40. Part III Dynamic Link Libraries

41. – 41 – STATIC LIBRARIES Build one or more libraries as “static libraries” Link the libraries with each project as needed  Advantages Simplifies and expedites project building  Disadvantages Disc and memory space issues Maintenance requires relinking and redistribution Different programs may use different library versions Programs cannot use alternate utility implementations for different situations

42. – 42 – DYNAMIC LINK LIBRARIES (1 of 4)  DLLs solve these and other problems very neatly Library functions are linked at: Program load time — implicit linking Program run time — explicit linking Program image can be much smaller It does not include the library functions Multiple programs can share a single DLL Only a single copy will be loaded into memory All programs map their process address space to DLL code Each thread will have its own copy of non-shared storage on the stack

43. – 43 – DYNAMIC LINK LIBRARIES (2 of 4)  New versions or alternate implementations: Supplying a new version of the DLL All programs can use the new version without modification  Explicit linking: Program decides at run time which library version to use Different libraries may be alternate implementations of the same function May carry out totally different tasks Just as separate programs do The library will run in the same process and thread as the calling program

44. – 44 – DYNAMIC LINK LIBRARIES (3 of 4)  DLLs are used in nearly every operating system Including UNIX and Windows 3.1 Windows (all versions) uses DLLs to implement the OS interfaces, among other things Windows 3.1 DLLs run at the same address space for all processes Windows DLLs run in the process’ virtual address space

45. – 45 – DYNAMIC LINK LIBRARIES (4 of 4)  Multiple Windows processes can share DLL code  Code, when called, runs as part of the calling process and thread Library can use the calling process’ resources (file handles,...) Uses the calling thread’s stack  DLLs must be thread-safe  DLLs can also export variables as well as function entry points

46. – 46 – IMPLICIT LINKING (1 of 2)  Implicit, or load-time, linking is the easiest of the two techniques  Steps: Collect and built function source as a DLL Build process constructs a.LIB library file “stub” for the actual code Place.LIB in project library directory Build process also constructs a.DLL file

47. – 47 – IMPLICIT LINKING (2 of 2) Contains the actual executable image Placed in the same directory as the application that uses it The current working directory is the secondary location Then system directory, Windows directory, PATH The program loads the DLL during its initialization You must “export” the function interfaces in the DLL source

48. – 48 – EXPORTING AND IMPORTING INTERFACES (1 of 3)  DLL entry point must be declared Microsoft C, using the _declspec (dllexport) storage modifier:  _declspec (dllexport)  DWORD MyFunction (...);  Calling program declares the function is to be imported Use the _declspec (dllimport) storage modifier

49. – 49 – EXPORTING AND IMPORTING INTERFACES (2 of 3)  Standard technique in include file Use a preprocessor variable such as “MYPROJ_EXPORTS“ “MYPROJ” is the project name #ifdef MYPROJ_EXPORTS #define LIBSPEC _declspec (dllexport) #else #define LIBSPEC _declspec (dllimport) #endif LIBSPEC DWORD MyFunction (...);

50. – 50 – EXPORTING AND IMPORTING INTERFACES (3 of 3) The DLL project defines MYPROJ_EXPORTS Calling application leaves MYPROJ_EXPORTS undefined  You can export and import variables as well as function entry points

51. – 51 – EXAMPLE–C  Build one or more of the ASCII to Unicode functions ( asc2un ) as a DLL. Export the entry point. Chapter 2 version is straightforward file I/O. It can be made faster with larger buffers, sequential scan flags, etc. Chapter 4 version uses memory mapping The two versions exhibit different performance characteristics depending on the file system type (NTFS or FAT)  Rebuild the atou calling program (Chapter 2) so that it implicitely links to a asc2un DLL

52. – 52 – EXPLICIT LINKING (1 of 4)  Explicit (run-time) linking requires: Program loads a DLL be loaded — LoadLibrary Finds the address of the entry point(s) — GetProcAddress Cast the address pointer to the function type Call the function using the pointer Optionally free the library — FreeLibrary NOTE: The function is not declared in the calling program; you declare a variable as a pointer to a function. Therefore, there is no need for the.LIB file at link time

53. – 53 – EXPLICIT LINKING (2 of 4)  HINSTANCE LoadLibrary (LPCTSTR lpLibFileName)  Returned handle is NULL on failure  HINSTANCE, rather than a conventional HANDLE It contains different information

54. – 54 – EXPLICIT LINKING (3 of 4)  BOOL FreeLibrary (HINSTANCE hLibModule)  You are done with the library or want a different version  LoadLibraryEx is similar Several flags for specifying alternate search paths and loading the library as a data file

55. – 55 – EXPLICIT LINKING (4 of 4)  To obtain the entry point: FARPROC GetProcAddress (HMODULE hModule, LPCSTR lpProcName)  hModule is an instance produced by LoadLibrary Or GetModuleHandle (not described here)  lpProcName is the entry point name Cannot be Unicode  NULL in case of failure  FARPROC, like “long pointer,” is an anachronism

56. – 56 – Loading a DLL  BOOL (*Asc2Un)(LPCTSTR, LPCTSTR, BOOL);  FARPROC pA2U;  /* Load the ASCII to Unicode function DLL file */  hDLL = LoadLibrary (argv [LocDLL]);  /* Get the entry point address */  pA2U = GetProcAddress (hDLL, "Asc2Un");  /* Convert to a function pointer */  Asc2Un = (BOOL (*)(LPCTSTR, LPCTSTR, BOOL)) pA2U;  /* Call the function */  Asc2Un (argv [LocFileIn], argv [LocFileOut],  FALSE);

57. – 57 – EXAMPLE–D (1 of 2)  Modify the atou program so that the name of the DLL file is on the command line Then load the DLL and call it, as illustrated on the previous slide

58. – 58 – EXAMPLE–D (2 of 2)  Here are some suggested extensions, not included in the lab solution: Modify the calling program so that it sequentially loads and calls several alternative implementations Modify the calling program so that it determines the operating environment (OS version, file system types, etc.) and then loads the most efficient implementation for the environment. Use your knowledge from previous performance experiments to determine the best implementation for a given situation.