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)

"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
that
> no gc routines get linked in, and all memory must be freed explicitly
(i.e.
> C style)

Sure. Try gc.disable() and gc.enable().

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

"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
> > 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.

> > 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?

"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.

> 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?

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.

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.

> 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.

"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.