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.

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

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.

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

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

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.

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).

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.

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