Designing with the GC out of mind

JS js.mdnq at gmail.com
Tue Aug 6 08:20:45 PDT 2013


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




More information about the Digitalmars-d mailing list