On 12/23/16 8:39 PM, Suliman wrote:
On Saturday, 24 December 2016 at 01:15:43 UTC, jkpl wrote:
On Friday, 23 December 2016 at 06:18:02 UTC, Suliman wrote:
I would like to visualize how GC works and display free/not free
memory segments.
How I can understand which of them are used and which not?

Could anybody explain what dangerous of memory fragmentation in
languages without GC? Am I right understand that there is stay some
small memory chunks that very hard to reuse?

You start with a wrong assumption. The C malloc functions is not just
a nasty and mean memory provider. Several implementations uses
internally freelists. Which means that the gaps created by a free()
may be filled again.

For example
- TCMallocator use free lists
- GCC C malloc use free lists (as stated here
http://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html)

- for snn.lib malloc (used by DMD win32) I can't say.

So there is no any problems with memory fragmentation and all used
memory arr successfuly reuse?


Strictly speaking fragmentation is a problem in D regardless of GC/nogc. The *only* way to reduce fragmentation is to use a compaction algorithm of some kind. Again this is separate from GC/nogc, because you could lock a memory pool you made and apply the same compaction algorithm, as opposed to using a GC algo.

For example, lets say you have the following unfragmented memory layout:
1111111122222333344444444444445555

Now delete the "four" memory:
11111111222223333-------------5555

And allocate a new "six" object, which just happens to fit inside the the space available on the freelist:
111111112222233336666666666---5555

Note the three dashes. Those will go unused until such time as an object small enough to fit inside is allocated. However, what happens if the object is not exactly the space available?

11111111222223333666666666677-5555

The dashes are what is commonly referred to as fragmentation. In that, small fragments of memory go unused because nothing fits inside them.

With a Precise GC you can implement a compacting collector that reorders blocks of memory within the address space to reduce or eliminate fragmentation.

--
Adam Wilson
IRC: LightBender
//quiet.dlang.dev

Reply via email to