On Mon, 24 Apr 2017 14:17:48 GMT, punkUser wrote:

On Sun, 23 Apr 2017 12:07:47 GMT, Sönke Ludwig wrote:

Unfortunately the GC is quite a pain point. dmd -vgc/dub -b profile-gc helps somewhat to find possible sources, but since it only accumulates allocations and ignores freed/collected memory, the numbers are not really suited to find memory leaks.

Yeah I've been keeping an eye out as you guys have been gradually shifting things to not use GC and wondering if I should do the same on some of my hotter code/allocation paths... if there was a good way of getting targeted information about which paths were hurting the most I would probably do that, but as you note it seems hard to understand "why is the GC leaving 50GB of address space sitting around", etc. It's not a giant issue for desktop use cases of course, but obviously with Vibe.d you're often trying to fit things into memory-starved VMs :)

Unfortunately it is not ready for general consumption and I had to put it on the back burner due to a general time shortage.

Ah, too bad, but I'll keep an eye out. In terms of basic high level information/sanity checks like how many fibers are currently alive/running/sleeping/whatever is there any easy way to get that information at runtime for logging purposes?

Thanks for the info!

There is no direct number to log, but setTaskEventCallback can be used to keep track of accumulated numbers, as well as could be used to assign allocations or other resource management operations to fibers. This is also the place where the debugger hooks into.