VWHPV ,&,,6 -XO $XJ ,QGLD An Efficient Heap Management ...Abstract- Heap management is responsible...

An Efficient Heap Management Technique with Minimum Fragmentation and

Auto Compaction

Krishna Lal. Baishnab, Soumyabrata Dev, Ziaul Haque Choudhury, Amlan Nag

[email protected], [email protected], [email protected], [email protected]

National Institute of Technology, Silchar Assam Abstract- Heap management is responsible for the allocation of heap segments to a running application. When the logic of the heap management is left to the application programmer, as it is the case with programming languages like C and C++, a number of problems may arise. One kind of problems related to imperfect heap management is that of memory fragmentation. Hence compaction of data is required to increase the efficient data storage capacity of the memory. Depending on whether active blocks within the heap may be shifted in position, one of the two approaches to compaction is possible: partial compaction and full compaction. But both these methods are too expensive and hence they are generally not used in large program modules. In this paper a new heap management technique MFAC (Minimum Fragmentation and Auto Compaction) is proposed which has an inherent auto compaction technique in its algorithm leading to minimum fragmentation of memory space. Simulation results show that in most scenarios, MFAC outperforms the 1st fit and best fit technique by a considerable margin.

I. INTRODUCTION The capability to dynamically allocate memory to a running application is an essential need for a wide range of software systems, and it is supported by most programming languages. The management of the dynamically allocated memory consists of two parts: the language primitives that allow the allocation and deallocation of heap segments, and the logic that controls these primitives. Some programming languages control tightly the heap management and come with runtime support that implements the logic for the heap management. Other programming languages provide only the heap allocation primitives but leave the development of the heap management logic to the programmer. An example of such a case is C, where the programmer can use calls like malloc() and free() to allocate and deallocate heap segments, and it is his/her own responsibility to correctly use these primitives in order to keep the heap in a consistent state. This case of heap management is more error-prone, and flaws in the logic of heap management are the source of some of the most persistent and difficult to correct software problems. Embedded software suffers a lot from memory leaks and double-frees, because often all the applications in the system run in a single process space. This implies that the heap space wasted or corrupted by one application does not only endanger its own execution, but it endangers also the execution of all other applications in the system, since all applications share the same heap. Another characteristic of

embedded software is that it often has to run on very limited resources and with real-time constraints. The combination of these two factors results in a prohibitive cost for the use of run time support for heap management. This is one of the reasons why embedded software relies mostly on the debugging of the heap management logic during the software test phase in order to remove memory leak and double-free errors. . One of the serious problems is the fragmentation error in memory. The system may give a memory full message even if the total free space is more than the requested memory slot. This is because there may be lack of contiguous memory space for its allocation. To this direction our proposed algorithm helps. It has an auto compaction technique which causes minimum fragmentation in the system. The rest of the paper is organized in the following manner. Section II summarizes previous work on dynamic memory management. Section III presents our proposed algorithm MFAC. The simulation results are shown in Section IV which has a comparative analysis with the first-fit and the best-fit technique of memory management. Section V concludes the paper.

II: PREVIOUS WORKS In recent research, studies have shown that object-oriented applications written in C++ can run upto 10 times slower than comparable C programs. This execution time overhead can largely be contributed to inefficient heap management algorithms. Since object-oriented applications tend to be more memory intensive than procedural ones, the ability to effectively manage heap memory is crucial to the performance of such systems. In software approaches, the DMM execution time is linearly proportional to the number of objects existing in the system. For example, as the calls to malloc intersperse with the calls to delete, the heap becomes increasingly fragmented and the occupied list and the free list become longer as well. In first fit approach, the list is searched from the beginning. The free block that is large enough to satisfy the request is then selected. If the block is larger than necessary, it is split and the remainder is put back on the free-list. The major problem with first fit is that the larger blocks at the beginning of the list are often split first. Since these blocks are often larger than the requested size, the remaining

978-1-4244-6653-5/10/$26.00 ©2010 IEEE

2010 5th International Conference on Industrial and Information Systems, ICIIS 2010, Jul 29 - Aug 01, 2010, India

266

portions are put back on the list. If the splitting occurs frequently, the beginning of the list may have many small unusable blocks. Therefore, the search time may increase since the search must go past them each time a larger block is requested. In best fit, the list is searched to find the smallest free block large enough to satisfy a request. The basic rational for this approach is to minimize the amount of fragmented space (caused by splitting). However, the problem may still occur if the selected block is not a perfect fit to the requested size. In such situation, splitting may put small memory blocks back to the list. These small blocks may be unusable. Additionally, the search in best fit is very exhaustive. Thus, this scheme may not scale well to large heaps with many free blocks.

III: OUR PROPOSED ALGORITHM At the very outset, several terminologies must be defined that we have used in the various parts of the algorithm. Free-list: This denotes the list of free nodes where memory can be allocated using the malloc() function. The generalized manner of expressing a free node is given as [a-b] where ‘a’ denotes the starting memory address location and ‘b’ denotes the number of contiguous available memory location. Whenever a number of free nodes become available after the application of free() function; they automatically get sorted with the existing nodes of the free list. For instance, the free list contains the node [a,b] and the nodes that have been de allocated are [c,d] and [e,f], then the sorted free list consist of [e,f]-[a,b]-[c,d] under the condition f

Hash map:

Fig 4: Hash Map-IV

Now, let there be a request then to free memory space at the location number 3 of the memory map. The node [3,5] attached to the memory loc 3 gets detached and gets sorted according to increasing memory space with the other nodes of the free list. The free list would look like [3,5]-[15,18] and the hash map as follows:

Fig 5: Hash Map-V

Next, assume that there is a request to allocate 6 bytes of memory space. In such scenarios, the proposed algorithm comes into play. Out of 6 bytes requested, it allocates 5 bytes starting from location number 3 and the remaining 1 byte from location number from loc no. 15. The free list becomes [16-17] and the hash map as follows:

Fig 6: Hash Map-VI

In the above step it is observed that the MFAC algorithm allocates the data in such a manner that the fragmentation is

minimum and data is compacted automatically. It is worthwhile to mention out here that in MFAC, it is not assumed that the allocated data is stored in contiguous memory location; it may get scattered over the entire empty memory space. In general cases, the starting memory address describes the whole chunk of data. The additional overhead in MFAC is a pointer that traverses through different memory locations as directed by the hash table. Continuing with the above case study, let us assume that the following operations take place in order: free the memory location at 11, then allocation of 7 bytes and 6 bytes respectively. The final hash map is given below for easy reference.

Fig 7: Hash Map-VII

IV. SIMULATION RESULTS

The proposed algorithm MFAC is simulated in C with the graphics library of Turbo C compiler graphics.h. A comparative analysis is made between MFAC, 1st fit and best fit algorithm and the memory map generated from the C code clearly indicates that MFAC outperforms the other technique by a considerable margin. MFAC causes the data to be compacted automatically causing to minimum fragmentation. The same sequence of events (as given in the case study of Section III) is observed in the simulator and the results generated are given below. The memory map clearly indicates that MFAC outperforms the other techniques by a considerable margin. As in the example when the last request to allocate 6 bytes of memory comes, MFAC could easily allocate free space to it. But on the other hand, 1st or best fit could not do so. It shows a message Memory Full. The complete pseudo code of the algorithm for the implementation of MFAC algorithm is given below. The flow chart has used a record type having two fields: address location (indicating the starting allocation point) and size (number of memory locations allocated). Algorithm: PSEUDOCODE OF ALGO Subroutine dealloc (int_addr)

If hash_map[-addr]!=NULL

then


268

Selection sort on the addr field of hash map Wrap-compact (hash_tabel[-addr] Else

Write (invalid address”) Print (Memory”) Exit (0); Subroutine

Wrap_component(node*addr) While (compact() !=0) Update_bit_mao(hash_map[-addr] return-to-freelist(hash_map[-addr] hash_map[-addr]= NULL return;

Subroutine alloc( int size) 1 Void *g 2 G=freelist 3 If g !=NULL

Then 4 Size=size-g->size 5 If sizeaddr,g->size-abs(size)) 7 Update_bit_map(hash_map[-addr] 8 Else 9 If size>0

Then 10 Add_to_hash_map(g-addr,g->size) 11 Delete_from_beg(free_list) 12 go to 3 13 else 14 add_to_hash_map(g-> addr,g->size) 15 deletefrom_beg(freelist) 16 end if 17 end if 18 endif

Fig 8: Memory Map in MFAC

Fig 9: Memory map in 1st and best fit algorithm


269

V. ANALYSIS OF MFAC & FUTURE EXTENSIONS MFAC has an auto compaction technique and hence it leads to minimum fragmentation (as shown above). But it is assumed that the data are not always stored in contiguous memory location. In general cases, it stores in contiguous memory location but in worst case scenarios, it is distributed over different part of empty memory space. The additional overhead is such scenario is a memory pointer that traverses through different parts of the memory in accordance to the linked list (as shown is hash table). The main challenge that MFAC model will face is the allocation of the trivial data structures like the arrays and the structures. Basically our model doesn’t support contiguous memory allocation and that may create problems in referring to the allocated trivial data structures. The hash map will come in handy in such scenarios. A deep analysis of the hash map reveals that the hash map is actually an image of the current state of the memory. The array elements are actually accessed by our original base+offset formula. In the hash map the base can be the pointer field in the first element of the list. Once we get the base pointer we can then add the offset to get the desired address. Suppose the offset is 12 and the hash map has the contents [1,4]-[2,5]-[5,10]. At the very outset, we need to find in which block of the hash map the offset belong. Adding 4 and 5 we get 4+5 = 9, as it is less than 12 and hence the desired block is somewhere in the block starting at the address 5. Since we are left with only (12-9) = 3 units and the number of contiguous free memory location at the location no. 5 is 10, so we calculate the desired value as 5+(12-9) = 5+3 = 8. Hence we get the desired value at memory location 8. The hash table that has been generated during the entire operation can be stored in virtual memory. In such cases, the program’s run-time requirement decreases considerably. Another modification that can be incorporated in MFAC is that a wilderness chunk from the virtual memory can be

appended to the end of heap area when it shows a memory full message. The virtual memory would then map memory pages from the main memory into the access memory. This will provide an infinite memory space to the heap. MFAC is still in its initial stages and several other modifications can be incorporated into it to increase its efficiency.

REFRENCES [1] Terrence W. Pratt, Marvin V. Zelkowitz, “Programming languages- design and implementation”, Prentice Hall –India [2] H. Verta, T. Saridakis, “detection of Heap management flaws in component based software” [3] T.Austin,S.Breach, and G.Sohi ,Efficient Detection of All Pointer and Array Access Errors. In Proceedings of the ACM SIGPLAN1994 Conference on Programming Language Design and Implementation (PLDI’94), pages 290 to 301,June 1994. [4] W.Bush, J.Pincus, and D.Sielaff. A Static Analyzer for Finding Dynamic Programming Errors. Software: Practice and Experience, 30(7):775-802,June2000. [5] C. Dan Lo, W. Srisa-an, J. M Chang , “The design and analysis of a quantitative simulator for dyanamic memory management”, the Journal of Systems and softwares. [6] Chang, J.M.,Srisaan, W.,Lo, C.D.,1999. Introduction to DMMX (Dynamic Memory Management Extension).In: Proceeding of ICCD Workshop on Hardware Support for Objects and Microarchitectures for Java, 10 October 1999, Austin, TX, pp.11-14. [7] Jhonstone, M.S., Wilson, P.R., 1998. The memory fragmentation problem: solved? In International Symposium on Memory Management, October 1998. Vancouver, British Columbia, Canada, pp.26-36. [8] Larson, P.A.,Krishnam, M. ,1998. Memory allocation for long-running server applications. In Proceedings of 1988 International Symposium on Memory Management, 1998, pp.176-185.


270

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 200 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 2.00333 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 400 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.00167 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/CreateJDFFile false /Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure false /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles true /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /NA /PreserveEditing false /UntaggedCMYKHandling /UseDocumentProfile /UntaggedRGBHandling /UseDocumentProfile /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice





































































/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 200 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 2.00333 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImag

VWHPV ,&,,6 -XO $XJ ,QGLD An Efficient Heap Management ...Abstract- Heap management is responsible...

Documents

Transcript of VWHPV ,&,,6 -XO $XJ ,QGLD An Efficient Heap Management ...Abstract- Heap management is responsible...