• Jeroen van Bemmel (6/6) Sep 02 2003 Walter,
• Walter (5/11) Sep 03 2003 that
• Dario (7/15) Sep 04 2003 No, Jeroen was looking for a way to use D without the gc, that is using
• Walter (6/22) Sep 04 2003 that
• Jeroen van Bemmel (6/14) Sep 04 2003 I got that. Again, what I was thinking about was a compiler switch that
• Walter (6/13) Sep 04 2003 D
• Mike Wynn (35/57) Sep 06 2003 as gc.d is in phobos, and all new ops are passed through there, you can
• Jeroen van Bemmel (6/10) Sep 07 2003 Bit off topic, but I used the V86 approach to call the BIOS. Not all BIO...
• Walter (12/36) Sep 09 2003 memmap is better for very large allocations, while malloc is suitable fo...
• Mike Wynn (11/22) Sep 09 2003 what mutex :)
• Matthew Wilson (12/16) Sep 04 2003 How hard would it be to have a compiler switch that disabled all gc and

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

"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

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

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

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

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

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

 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.

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.

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

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

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)

"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

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.