On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote:
Are there any disallowed memory operations?

Currently can't touch GC from destructor during collection. Another concern is interoperability with C-allocated memory: GC knows nothing about C heap.

How often does it leak?

Leaks are likely in 32-bit processes and unlikely in 64-bit processes. See e.g. https://issues.dlang.org/show_bug.cgi?id=15723

Do I need to be careful with some operations to avoid leaks?

Leaks happen only due to false pointers. But data allocated in GC with new operator and known to have no pointers (e.g. strings) is not scanned. Premature collection happen when GC doesn't see a pointer to the allocated data, happens when such pointer is put in a memory GC doesn't see, like C heap.

Is a precise GC in the roadmap?

There's an effort on it: https://forum.dlang.org/post/hdwwkzqswwtffjehe...@forum.dlang.org

It's fine if I have to do manual memory management, but I don't want any leaks.

If you manually deallocate memory, it gets deallocated for sure, shouldn't leak. Comparing to java, D GC trades GC performance for code execution performance, which can result in better overall performance when you don't allocate much and worse performance for allocation-heavy code that java GC is optimized for.

Reply via email to