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?

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