Can "pragma pack 1" be helpful to avoid heap fragmentation?
Asked Answered
I

5

11

In my program I see some resident size increase. I suppose it is because of heap fragmentation. So I am planning to use #pragma pack 1. Will it reduce the heap fragmentation?

Will it be having some other overheads?

Shall I go for it or not?

Irenairene answered 6/5, 2014 at 7:3 Comment(4)
It may actually increase heap fragmentation, if the heap allocator tries to allocate on nice native word boundaries and the structure is no longer padded to nice native word boundaries.Dalton
You will suffer a performance penalty for mal-aligned memory accesses, which might be worse than what you are trying to archieve (decrease size of objects) Also, did you check for memory leaks, instead of assuming it is heap fragmentation?Subir
yaa. i was using valgrind to find out memory leaks. In valgrind report i don't see any leaks. But the RSS is increasing and that itself is a question.Irenairene
I suggest to use a specific allocator to avoid fragmentation instead.Soledadsolely
F
4

Packing structures probably won't have much affect on heap fragmentation. Heap fragmentation normally occurs when there is a repeating pattern of allocations and freeing of memory. There are two issues here, one issue is that the virtual address space gets fragmented, the other issue is that physical 4k pages end up with unused gaps, consuming increasing amounts of memory over time. Microsoft addresses the 4k page issue with it's .net framework that occasionally repacks memory, but does so by "pausing" a .net application during the repacks. I'm not sure how server apps that run 24 hours a day / 7 days a week deal with this without having to deal with the pauses, unless they occasionally fork off a new process to take over the server side and then close down the old process which would refresh the new process virtual address space with a new set of pages.

Fact answered 6/5, 2014 at 7:34 Comment(1)
Update - Microsoft Azure includes automatic "load balancing", switching between cores and/or processors as needed, including during .net repacks.Fact
B
10

There is a well proved technique called Memory pools. It is designed especially to reduce memory fragmentation and help with memory leaks. And it should be used in case where memory fragmentation became the bottleneck of the program functionality.

'pragma pack 1' isn't helpful to avoid heap fragmentation.

'pragma pack 1' is used to remove the padding bytes from structures to help with transmission of binary structures between programs.

Bignoniaceous answered 6/5, 2014 at 7:50 Comment(3)
Good suggestion, although I'm wondering how Memory pools would help with memory leaks?Lennie
lethal-guitar, this relates more to the c, not c ++. Suppose, you want to be sure what were is no memory leaks after client has been disconnected from web server. How to achieve that? When client connect to server, you create a memory pool (allocate one big array using OS malloc). Inside client handling code you ask the memory pool to allocate memory for objects, not OS. Then client disconnect from server, you deallocate whole pool (using free). For examples google for 'APR memory pools' and 'pjsip Fast Memory Pool'. See dev.ariel-networks.com/apr/apr-tutorial/html/….Bignoniaceous
It's also where the Heartbleed bug originated. ;-)Rosenwald
D
6

It's simply how the operating system works. When you free some memory you've allocated, it's not unmapped from the process memory map. This is kind of an optimization from the OS in case the process needs to allocate more memory again, because then the OS doesn't have to add a new mapping to the process memory map.

Dalton answered 6/5, 2014 at 7:30 Comment(0)
C
5

#pragma pack N, tells the compiler to align members of structure in a particular way, with (N-1) bytes padding. For example, if N is 2, each char will occupy 2 bytes, one assigned, one padding. With N being 1, there will be no padding. This will have more fragmentation, as there would be odd number of bytes if the structure has say one char and one int, totaling 5 bytes. Check: #pragma pack effect

Cretinism answered 6/5, 2014 at 7:17 Comment(1)
For default pack handling, single character variables in a structure will not be padded, but larger types will be padded to boundaries corresponding to their type, except 8 byte types like doubles or long longs may not be put on 8 byte boundaries if the default pack value is 4.Fact
F
4

Packing structures probably won't have much affect on heap fragmentation. Heap fragmentation normally occurs when there is a repeating pattern of allocations and freeing of memory. There are two issues here, one issue is that the virtual address space gets fragmented, the other issue is that physical 4k pages end up with unused gaps, consuming increasing amounts of memory over time. Microsoft addresses the 4k page issue with it's .net framework that occasionally repacks memory, but does so by "pausing" a .net application during the repacks. I'm not sure how server apps that run 24 hours a day / 7 days a week deal with this without having to deal with the pauses, unless they occasionally fork off a new process to take over the server side and then close down the old process which would refresh the new process virtual address space with a new set of pages.

Fact answered 6/5, 2014 at 7:34 Comment(1)
Update - Microsoft Azure includes automatic "load balancing", switching between cores and/or processors as needed, including during .net repacks.Fact
P
4

If you're specifically concerned about heap fragmentation then you might want to increase the structure packing. This would (occasionally) result in different structures being distributed between fewer different-sized buckets and reducing the likelihood of allocations leaving unusable gaps when they occupy the space of a previously-freed, slightly larger structure.

But this is unlikely to be your real concern. As another answer points out, the OS does not reclaim freed memory right away, and this can affect the apparent memory usage of the process.

Plaster answered 6/5, 2014 at 7:41 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.