On Tuesday, 6 August 2013 at 14:27:32 UTC, Adam D. Ruppe wrote:
On Tuesday, 6 August 2013 at 13:43:01 UTC, JS wrote:
I'd still like some easy way to hook into the GC to monitor
what is going on though because ultimately I'd like to disable
the GC but then must guarantee that memory is not leaking.
Using a debugger is the easiest way. You can also hack on
druntime (various ways to do this, including one option that
doesn't actually edit druntime, linked to earlier in this
thread).. and there's a gc proxy in the code but idk how to use
it.
The issue is I may want to use the GC at runtime for various
tasks but disable clean up until the appropriate time. Also,
without some automated way to see what the GC is doing, it would
be a nightmare to have to debug it every time some library
function is added to see if it's using the GC. (e.g., file
functions, etc...)
It would be easier and more informative just to hook into the GC
and then report statistics at the end of the program. I could
then, by using my allocation strategies, see how beneficial they
are.
seems the typeid you mention should solve this(but to be
honest, I don't know if it will completely solve the issue or
how performant it is).
typeid just fetches the TypeInfo, so they're the same thing I'm
not sure how fast it is to fetch that info, but that's what the
gc does so you're at least no worse off.
I guess I'll have to do some sleuthing at some point to see what
exactly is happening...
