Support a preallocate-all GC scheme

keinfarbton Joined: 12/03/05 Posts: 49

Posted: 08/20/07 18:06:24 In situations where it is not possible to allow GC runs, it would be cool to have this. Therefore the GC needs to have one more methods: allocationsAllowed( bool enable ); if the application calls allocationsAllowed( false ), any allocation, even from the tango internals will cause an exception to happen. In this case, it should be a subclass of TracedException?. This allows applications to detect there memory leaks quickly.

Author	Message
kris Joined: 03/27/04 Posts: 581	Posted: 09/02/07 00:12:16 good idea, keinfarbton ... this should perhaps become a ticket instead?
div0 Joined: 09/10/07 Posts: 13	Posted: 09/19/07 19:42:28 kris wrote: good idea, keinfarbton ... this should perhaps become a ticket instead? tango.core.Memory.GC.disable() ?!
schveiguy Joined: 08/02/07 Posts: 128	Posted: 09/19/07 20:40:31 div0 wrote: tango.core.Memory.GC.disable() ?! This seems to only disable the running of the collector... I think keinfarbton is asking to prohibit allocating NEW memory. -Steve
div0 Joined: 09/10/07 Posts: 13	Posted: 09/19/07 20:57:52 schveiguy wrote: div0 wrote: tango.core.Memory.GC.disable() ?! This seems to only disable the running of the collector... I think keinfarbton is asking to prohibit allocating NEW memory. -Steve Ah. seems a bit pointless though, except as a debugging tool. Surely if you're that paranoid you aren't going to be calling any library functions at all? You couldn't take an arbitrary bit of code and then just disallow allocating, the code would have to be designed with that restriction in mind or you'd spend forever tracing every execution path to find and modify any bits that allocate memory. Maybe it would make more sense to add some sort of hooks into the gc, so people can have more fine grained control. Sort of a pre-allocate event, a pre-collection event, etc.
kris Joined: 03/27/04 Posts: 581	Posted: 09/19/07 21:32:35 -- Modified: 09/19/07 21:52:31 by kris Interestingly, Tango is designed in a manner where this would work for large parts of it. Once you have a given set of objects, you can generally get by without using the heap. This is how the Mango HTTP and Servlet servers, along with Tango clustering, manage to avoid using the heap at all once they are actually running. I can definitely see a use for this as a type of profiling tool; imagine if you'd setup your classes to do custom allocation instead, and wanted to ensure the generic heap was not being touched?
div0 Joined: 09/10/07 Posts: 13	Posted: 09/19/07 22:38:13 kris wrote: Interestingly, Tango is designed in a manner where this would work for large parts of it. Once you have a given set of objects, you can generally get by without using the heap. This is how the Mango HTTP and Servlet servers, along with Tango clustering, manage to avoid using the heap at all once they are actually running. I can definitely see a use for this as a type of profiling tool; imagine if you'd setup your classes to do custom allocation instead, and wanted to ensure the generic heap was not being touched? Move the gc into a separate lib and provide a standard version and a hooked/profiled version? That sounds kinda cool actually, pick your gc depending on your aims... The main d page already recommends passing the gc instance to dlls so if you where really paranoid/bottle necked, you could pick a debug version with a gc that does logging of allocations with type info. Somebody was asking along similar lines with regards to minid, for game development.
kris Joined: 03/27/04 Posts: 581	Posted: 09/19/07 22:53:34 I'd love to stick the GC into a DLL, but D doesn't support DLLs in any practical way (you can't throw exceptions across DLL boundaries). Basically, D + DLLs == 0 :(
div0 Joined: 09/10/07 Posts: 13	Posted: 09/20/07 18:44:03 nope, I wasn't on about putting the gc in a dll. just seperate it out into a separate lib and then providing a debug/hooked version. so you'd just add a -L+gcDebug to your command line to override the default. are you sure about not being able to throw exceptions across dlls? works fine in c++ and I can't see why D would be any different. there used to be issues with allocating memory in different dlls with visual studio 6, but they fixed that in .net 2003
kris Joined: 03/27/04 Posts: 581	Posted: 09/20/07 21:17:24 Yeah, I was going one step further with the GC :) There's a lot of issues with D & Dlls ... the fact that typeinfo is not shared is one root issue. There's good reason why the DDL project has written their own link-loader
sean Joined: 06/24/04 Posts: 109	Posted: 09/21/07 16:50:52 div0 wrote: nope, I wasn't on about putting the gc in a dll. just seperate it out into a separate lib and then providing a debug/hooked version. The GC already builds as a separate lib when build-dmd / build-gdc is called, so most of the work is aready done. Now that DMD provides a means of specifying separate libraries for release and debug builds, I'm going to build both versions of each lib during the build process. Stay tuned.
keinfarbton Joined: 12/03/05 Posts: 49	Posted: 11/20/07 19:05:13 I forgot to mention, I had made ticket #610
sean Joined: 06/24/04 Posts: 109	Posted: 11/21/07 18:49:30 Thanks. It seems the greatest obstacle now is that the DigitalMars? make tool stinks.