Is there any heap compaction in C/C++ runtime?

[hs_intel]

Before I start, I want to say that I know very little about Intel's compiler products.

I want to know if Intel provides C/C++ runtime also along with its compiler (especially on linux) or do we have to link with other runtime libraries?

If it does, then does the C/C++ runtime do heap compaction? Or in other words, if the address of objects stored in pointers or long can ever change?

[TimP]

Intel C and C++ rely on the run-time provided with the base compiler (CL from Visual Studio or (for linux) g++), with minor augmentation, and provide interoperability with those compilers. 3rd party heap managers used to be popular, but I don't know that any of them had your favorite feature.

[Michael_K_Intel2]

Quoting - tim18

Intel C and C++ rely on the run-time provided with the base compiler (CL from Visual Studio or (for linux) g++), with minor augmentation, and provide interoperability with those compilers. 3rd party heap managers used to be popular, but I don't know that any of them had your favorite feature.

Hi!

Heap compaction is virtually impossible in C/C++. As with heap compaction pointers to heap data changes when the heap is compacted, all pointers that point to the heap would have to be adjusted. Either compiler support is needed, as the compiler must keep track of all pointers and pointer operators and inform the heap compactor about how to change the pointers to reflect the new heap location. Or pointers have to be indirected, that is, point to a heap table that in turn points to the actual data on the heap.

In managed languages, e.g. Java, heap compaction (or copying garbage collectors) becomes possible, as there are no pointers. Java references do not necessarily directly point into the heap, but instead might point to a heap table entry. It is also possible that the virtual machine keeps track of Object references and knows how to readjust them to point to the new heap structure after compaction.

While garbage collectors for C++ exist, they usually don't do heap compaction as this would be to expense (because of the needed pointer adjustments).

Cheers,
-michael

[jimdempseyatthecove]

Quoting - hs_intel

Before I start, I want to say that I know very little about Intel's compiler products.

I want to know if Intel provides C/C++ runtime also along with its compiler (especially on linux) or do we have to link with other runtime libraries?

If it does, then does the C/C++ runtime do heap compaction? Or in other words, if the address of objects stored in pointers or long can ever change?

Upon allocation the pointer (address of allocation) returned will remain fixed. Anything the heap does will not affect this. You could define your own pointer type that permits relocation/compaction.

Upon deallocation we have a different story. I will speak for Windows, Linux may have a similar issue.

Windows has multiple types of heaps. The default heap is designed for speed .AND. to overcome a problem of use of buffer after deallocation (buggy code). In this mode, deallocations are not immediately consolidated (adjacent deallocations are not immediately joined together). This results in the heap getting fragmented. When fragmentation gets large, allocations may fail.

Windows also has a heap mode called the Low Fragmentation Heap (LFH). In this mode, deallocations are slower but adjacent deallocations are immediately joined together.

Since you are on Linux, you might want to search the library docs or internet for information relating to "Low Fragmentation Heap" although the phrasing of this term might be different.

Jim Dempsey

[hs_intel]

Thanks Jim

[hs_intel]

Thanks Michael and tim18