digitalmars.D - more control over GC
Maybe some or all of the below is nonsence, but I'm just thinking... 1) What if [a very special kind of] an application were able to do something like gc.enableStopTheWorld(TRUE/FALSE). TRUE is how things work now. During the time when set to FALSE, application guarantees not to do any memory allocation/deallocation (and maybe some other operations, don't know). This way, an application with serious real-time requirements would mostly run in FALSE mode, but sometimes for parts requiring sophisticated memory management it would either temporarily switch to TRUE or better temporarily disable GC. This way gc could run smoothly in a low-prioritized thread and never freeze anything at all. 2) What if it were possible to exclude a particular thread from threads stopped by the GC (during that time the thread won't probably be allowed to do any memory allocation/deallocation [and again maybe more operations]) 3) Given an application guaranteeing never spawning any threads, a single thread application. If the compiler would be aware of that fact, could it produce faster and/or smaller code? 4) If an application for some reason does not need any GC, it would be good to be able to tell the compiler not to include any GC code into the program. Any suggestions?
May 14 2005
xs0 <xs0 xs0.com> B.G. wrote:Maybe some or all of the below is nonsence, but I'm just thinking... 1) What if [a very special kind of] an application were able to do something like gc.enableStopTheWorld(TRUE/FALSE). TRUE is how things work now. During the time when set to FALSE, application guarantees not to do any memory allocation/deallocation (and maybe some other operations, don't know). This way, an application with serious real-time requirements would mostly run in FALSE mode, but sometimes for parts requiring sophisticated memory management it would either temporarily switch to TRUE or better temporarily disable GC. This way gc could run smoothly in a low-prioritized thread and never freeze anything at all.Well, AFAIK: - the current GC has to stop the world to be able to do any collecting at all, so the only thing you can do is to disable it, which is possible already :) - still, if you don't allocate any memory, GC will not kick in, so if your app doesn't allocate memory (in some part of code), you won't get frozen either2) What if it were possible to exclude a particular thread from threads stopped by the GC (during that time the thread won't probably be allowed to do any memory allocation/deallocation [and again maybe more operations])Well, it's not so much allocation/deallocation that is the problem, but the references/pointers the thread is holding; if GC doesn't inspect those, it may collect some stuff that is not garbage. And, in order to do the inspection, the thread must be frozen.. The only threads where not inspecting would make any sense at all, is threads that don't hold any pointers or references to anywhere, except their own stack data and static globals, which I'd say are quite rare :) Anyway, you have the option of creating the thread by using native OS API, and that will exclude them from GC (although be certain your threads fit the profile)3) Given an application guaranteeing never spawning any threads, a single thread application. If the compiler would be aware of that fact, could it produce faster and/or smaller code?Yup, if nothing else, it could ignore every volatile and synchronized, allowing more optimizations to happen. OTOH, if you don't use those, I think there wouldn't be much difference; their purpose is ensuring thread-safe code, so if you're not using them, the code is optimized for the non-threaded case anyway (or at least it could/should be)..4) If an application for some reason does not need any GC, it would be good to be able to tell the compiler not to include any GC code into the program.You can do that by hacking Phobos (the standard library), although I haven't looked at it much, so I have no idea how hard or easy that is.. xs0
May 14 2005