www.digitalmars.com         C & C++   DMDScript  

D - can gc be disabled?

reply "Jeroen van Bemmel" <someone somewhere.com> writes:
Walter,

Is there a way to disable the use of gc globally? A situation where you
might want this, is if you are building an OS core. It could eg be
implemented as a compiler option such as '-nogc'. The effect should be that
no gc routines get linked in, and all memory must be freed explicitly (i.e.
C style)
Sep 02 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bj42e2$1q00$1 digitaldaemon.com...
 Walter,

 Is there a way to disable the use of gc globally? A situation where you
 might want this, is if you are building an OS core. It could eg be
 implemented as a compiler option such as '-nogc'. The effect should be

 no gc routines get linked in, and all memory must be freed explicitly

 C style)

Sure. Try gc.disable() and gc.enable().
Sep 03 2003
parent reply Dario <Dario_member pathlink.com> writes:
Jeroen van Bemmel says:
 Walter,

 Is there a way to disable the use of gc globally? A situation where you
 might want this, is if you are building an OS core. It could eg be
 implemented as a compiler option such as '-nogc'. The effect should be that
 that
 no gc routines get linked in, and all memory must be freed explicitly
 (i.e. C style)

Walter says:
Sure. Try gc.disable() and gc.enable().

No, Jeroen was looking for a way to use D without the gc, that is using 'new' to allocate and 'delete' to free like C++ does. In short, how to use D with C++ memory management phylosophy. Since phobos is based on the gc, it probably has to be changed. Dario
Sep 04 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Dario" <Dario_member pathlink.com> wrote in message
news:bj7ed3$dkc$1 digitaldaemon.com...
 Jeroen van Bemmel says:
 Walter,

 Is there a way to disable the use of gc globally? A situation where you
 might want this, is if you are building an OS core. It could eg be
 implemented as a compiler option such as '-nogc'. The effect should be


 that
 no gc routines get linked in, and all memory must be freed explicitly
 (i.e. C style)

Walter says:
Sure. Try gc.disable() and gc.enable().

No, Jeroen was looking for a way to use D without the gc, that is using 'new' to allocate and 'delete' to free like C++ does. In short, how to use D with C++ memory management phylosophy. Since phobos is based on the gc, it probably has to be changed. Dario

I'm sorry, I misunderstood. While new and delete can be defined on a per-class basis, there's no way to do it globally, although one can use malloc/free as in C.
Sep 04 2003
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 No, Jeroen was looking for a way to use D without the gc, that is using
 'new' to allocate and 'delete' to free like C++ does. In short, how to
 use D with C++ memory management phylosophy.
 Since phobos is based on the gc, it probably has to be changed.
 Dario


Correct, although I might consider not using phobos at all. I was curious to see how minimalistic D can get
 I'm sorry, I misunderstood. While new and delete can be defined on a
 per-class basis, there's no way to do it globally, although one can use
 malloc/free as in C.

I got that. Again, what I was thinking about was a compiler switch that disables the generation and linking in of GC code/library routines. Since D is (also) aimed at systems programming, I figured it might be possible. How many OSs do you know that do garbage collection at kernel level?
Sep 04 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bj86os$1hdv$1 digitaldaemon.com...
 I'm sorry, I misunderstood. While new and delete can be defined on a
 per-class basis, there's no way to do it globally, although one can use
 malloc/free as in C.

disables the generation and linking in of GC code/library routines. Since

 is (also) aimed at systems programming, I figured it might be possible.

 many OSs do you know that do garbage collection at kernel level?

Maybe it's time there should be one. After all, GC can be made to work much better if it has access to the hardware VM support.
Sep 04 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 "Jeroen van Bemmel" <someone somewhere.com> wrote in message
 news:bj86os$1hdv$1 digitaldaemon.com...
 
I'm sorry, I misunderstood. While new and delete can be defined on a
per-class basis, there's no way to do it globally, although one can use
malloc/free as in C.

I got that. Again, what I was thinking about was a compiler switch that disables the generation and linking in of GC code/library routines. Since

D
is (also) aimed at systems programming, I figured it might be possible.

How
many OSs do you know that do garbage collection at kernel level?

Maybe it's time there should be one. After all, GC can be made to work much better if it has access to the hardware VM support.

as gc.d is in phobos, and all new ops are passed through there, you can abuse the system to your hearts content. unfortunalty, you can not influence the code generator (so no ref bits on the stack etc) but I think you could change the classinfo struct (not tried yet) and do things like per class caching of memory blocks. not quite got a GC'd kernel yet, but have abused phobos to allow it to run in a flat 32 bit no paging prot mode env ..... http://www.geocities.com/one_mad_alien/dkernel.html currenly the GC misses the statics (not sure why, I seem to be registering the correct range) but I've cut 80% of the D support code out ..... Walter: is there a reason why 2 malloc's are neeeded ? gc init uses c malloc allocate space for the gcx obj, then calls memmap to get its own managed space. this is a pain for an OS (I have to have 2 heaps) I see no reason that gc.init can not use memmap, get its initial 1 Meg chunk, cut out the first block as the gcx object, register it with itself and continue, all following mallocs are via gc.malloc anyway. and how do I get intrinsics to be intrinsic [x86 linux (rh9.0)] dmd 0.71 i.e intrinsic.btr wants a btr func (rather than being inlined by dmd) and what are the times when the gc may go off, I assume its only on alloc (new) or gc.collect (so no alloc's in isr's) are there any other times that a gc cycle may be started up (enter/exit frame/scope, backwards branch etc). and does nested func -> delegate cause any allocations, are they usable in "hard realtime" envs? does gc.enable() cause a gc cycle ? (again can an isr do gc.disable();alloc;gc.enable();iret or is that just plain nasty) not that I think an isr should alloc, but I was thinking as an experiment to have the keyboard isr create keyup/keydown event objects and fill a ring buffer / queue. if anyone has written a v86 task plz I could do with the code to call the bios from 32 prot mode (although I believe a few stratigically placed 286 (16bit) prot mode segments and call/task gate or two might allow bios calls without leaveing prot mode.
Sep 06 2003
next sibling parent "Jeroen van Bemmel" <someone somewhere.com> writes:
 if anyone has written a v86 task plz I could do with the code to call
 the bios from 32 prot mode (although I believe a few stratigically
 placed 286 (16bit) prot mode segments and call/task gate or two might
 allow bios calls without leaveing prot mode.

Bit off topic, but I used the V86 approach to call the BIOS. Not all BIOSes support 32-bit PM calls, and not for all functions (e.g. VESA version 2.x up does support it, but then other parts dont) It depends a bit what you need it for: I needed the SVGA mode initialization (didn't want to write that myself yet) so in that case speed is not really an issue, V86 mode works fine there.
Sep 07 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bje5q3$19k9$1 digitaldaemon.com...
 Walter: is there a reason why 2 malloc's are neeeded ?
 gc init uses c malloc allocate space for the gcx obj, then calls memmap
 to get its own managed space. this is a pain for an OS (I have to have 2
 heaps) I see no reason that gc.init can not use memmap, get its initial
 1 Meg chunk, cut out the first block as the gcx object, register it with
 itself and continue, all following mallocs are via gc.malloc anyway.

memmap is better for very large allocations, while malloc is suitable for small ones. malloc is usually there anyway because of the C runtime.
 and how do I get intrinsics to be intrinsic [x86 linux (rh9.0)] dmd 0.71
 i.e intrinsic.btr wants a btr func (rather than being inlined by dmd)

That's probably a compiler bug.
 and what are the times when the gc may go off, I assume its only on
 alloc (new) or gc.collect (so no alloc's in isr's)

Yes.
 are there any other times that a gc cycle may be started up (enter/exit
 frame/scope, backwards branch etc).

No.
 and does nested func -> delegate cause any allocations,

No.
 are they usable
 in "hard realtime" envs?

Yes.
 does gc.enable() cause a gc cycle ? (again can an isr do
 gc.disable();alloc;gc.enable();iret or is that just plain nasty)

No.
 not that I think an isr should alloc, but I was thinking as an
 experiment to have the keyboard isr create keyup/keydown event objects
 and fill a ring buffer / queue.

gc is thread safe. If you're using an isr to allocate gc memory, you'll need to fix the mutexes on the gc.
 if anyone has written a v86 task plz I could do with the code to call
 the bios from 32 prot mode (although I believe a few stratigically
 placed 286 (16bit) prot mode segments and call/task gate or two might
 allow bios calls without leaveing prot mode.

Sep 09 2003
parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 "Mike Wynn" <mike l8night.co.uk> wrote in message
 news:bje5q3$19k9$1 digitaldaemon.com...
 
not that I think an isr should alloc, but I was thinking as an
experiment to have the keyboard isr create keyup/keydown event objects
and fill a ring buffer / queue.

gc is thread safe. If you're using an isr to allocate gc memory, you'll need to fix the mutexes on the gc.

what mutex :) currently the kernel is a single thread flat 32 bit so all the lock code is removed, I should put a cmpxchng in there to check that isrs are not allocating any memory. as an aside, the Java realtime spec (don't know if realtime Java is still around) has a mechanism where you can preallocate memory (thread local) that can be used for the next allocations. object are allocated in order (stack like so constant time operation) from it until you request more (in which case the old chuck is returned to the normal heap)
Sep 09 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 I got that. Again, what I was thinking about was a compiler switch that
 disables the generation and linking in of GC code/library routines. Since

 is (also) aimed at systems programming, I figured it might be possible.

 many OSs do you know that do garbage collection at kernel level?

How hard would it be to have a compiler switch that disabled all gc and instead made all instances auto? Since you have the mechanism for auto there, perhaps not hard. Of course then we might run up against the conceptual issues regarding treating finalising types as RAII types (of which there seems to be much obtuse debate on c.l.c.m recently). I don't know what the ramifications are. Converesly, this would be a fabulous way to actually test out such unknowns, as well as practically a great way to check whether one's finalisation code for all types is actually correct. Damn! I am seeing both sides of both sides again.
Sep 04 2003