www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - more control over GC

reply B.G. <B.G._member pathlink.com> writes:
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
parent xs0 <xs0 xs0.com> writes:
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 either
 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])

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