Re: Hooking into GC
On Thursday, 30 June 2016 at 03:03:16 UTC, MMJones wrote: I need to get more info than just the memory usage. Like what is using the memory. That's what -profile-gc is for, it tracks allocations. Give it a try, IIIRC it's missing explicit GC.malloc calls atm., but those should be rare anyhow and could be added. http://dlang.org/changelog/2.068.0.html#profile-gc
Re: Hooking into GC
On Thursday, 30 June 2016 at 01:26:47 UTC, Martin Nowak wrote: On Wednesday, 29 June 2016 at 14:41:48 UTC, MMJones wrote: On Wednesday, 29 June 2016 at 10:07:19 UTC, Martin Nowak wrote: How will this affect the trackallocs module? Will it break it, replace it? Essentially a merge of it? Should I hold off until 2.072 or go ahead and use the stub. I only need monitoring, not replacement of the GC. It'll break it b/c we've replaced the proxy with a real interface. I think your use-case is fully covered by the GC profiler (http://forum.dlang.org/thread/mi62uu$14lu$1...@digitalmars.com) and GC stats (https://dlang.org/spec/garbage.html#gc_config, https://github.com/dlang/druntime/pull/1591). I need to get more info than just the memory usage. Like what is using the memory.
Re: Hooking into GC
On Wednesday, 29 June 2016 at 14:41:48 UTC, MMJones wrote: On Wednesday, 29 June 2016 at 10:07:19 UTC, Martin Nowak wrote: How will this affect the trackallocs module? Will it break it, replace it? Essentially a merge of it? Should I hold off until 2.072 or go ahead and use the stub. I only need monitoring, not replacement of the GC. It'll break it b/c we've replaced the proxy with a real interface. I think your use-case is fully covered by the GC profiler (http://forum.dlang.org/thread/mi62uu$14lu$1...@digitalmars.com) and GC stats (https://dlang.org/spec/garbage.html#gc_config, https://github.com/dlang/druntime/pull/1591).
Re: Hooking into GC
On Wednesday, 29 June 2016 at 10:07:19 UTC, Martin Nowak wrote: On Wednesday, 29 June 2016 at 02:18:27 UTC, MMJones wrote: I read somewhere that one can modify the D files from phobos and runtime to supply a stub for the GC. I would like to add some logging features to the GC. Does this not require one to recompile phobos? I figured the source code was just for debugging? I'm curious if I can really get away with modifying the source code in dmd2's dir and it will actually work. I guess I could try but I don't wanna go mess with it if it's not going to do anything. Going to be released with 2.072.0 https://github.com/dlang/druntime/pull/1581 How will this affect the trackallocs module? Will it break it, replace it? Essentially a merge of it? Should I hold off until 2.072 or go ahead and use the stub. I only need monitoring, not replacement of the GC.
Re: Hooking into GC
On Wednesday, 29 June 2016 at 02:18:27 UTC, MMJones wrote: I read somewhere that one can modify the D files from phobos and runtime to supply a stub for the GC. I would like to add some logging features to the GC. Does this not require one to recompile phobos? I figured the source code was just for debugging? I'm curious if I can really get away with modifying the source code in dmd2's dir and it will actually work. I guess I could try but I don't wanna go mess with it if it's not going to do anything. Going to be released with 2.072.0 https://github.com/dlang/druntime/pull/1581
Re: Hooking into GC
On 06/28/2016 08:39 PM, MMJones wrote: > Yeah, I saw that. I'm looking the general answer though. Not just for > GC. Does D basically combine the d files in to phobos when they are > modified? No. Somebody must explicitly build the library. However, any code that's templated cannot be pre-built because it must work with user-defined types, which the compiler cannot be aware of ahead of time. > What if I want to log all file operations? It would be easier to stick a > log function in std.file but I have a feeling it won't be recompiled and > used. It won't work with the non-templated parts of the library but go ahead and modify almost anything in std.algorithm and you will see the effect as soon as you compile your program. :) Ali
Re: Hooking into GC
On Wednesday, 29 June 2016 at 03:10:10 UTC, thedeemon wrote: On Wednesday, 29 June 2016 at 02:18:27 UTC, MMJones wrote: I read somewhere that one can modify the D files from phobos and runtime to supply a stub for the GC. I would like to add some logging features to the GC. You don't need to recompile anything, a stub can be installed from your program. See an example (which can do logging) here: https://bitbucket.org/infognition/dstuff/src/97cef6d4a0438f9a9f4ff0d18f819262b8a74888/trackallocs.d?fileviewer=file-view-default Yeah, I saw that. I'm looking the general answer though. Not just for GC. Does D basically combine the d files in to phobos when they are modified? What if I want to log all file operations? It would be easier to stick a log function in std.file but I have a feeling it won't be recompiled and used.
Re: Hooking into GC
On Wednesday, 29 June 2016 at 02:18:27 UTC, MMJones wrote: I read somewhere that one can modify the D files from phobos and runtime to supply a stub for the GC. I would like to add some logging features to the GC. You don't need to recompile anything, a stub can be installed from your program. See an example (which can do logging) here: https://bitbucket.org/infognition/dstuff/src/97cef6d4a0438f9a9f4ff0d18f819262b8a74888/trackallocs.d?fileviewer=file-view-default
Hooking into GC
I read somewhere that one can modify the D files from phobos and runtime to supply a stub for the GC. I would like to add some logging features to the GC. Does this not require one to recompile phobos? I figured the source code was just for debugging? I'm curious if I can really get away with modifying the source code in dmd2's dir and it will actually work. I guess I could try but I don't wanna go mess with it if it's not going to do anything.