www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - [D newbie - long] A lot of questions about D: Binary Modules, Metadata, Memory Management

reply Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
I've a long (10 years) experience in C++ programming, but now I'm
at the point "fed up": I can't take it any more. In my
experience C++ is nice for self contained, monolithic programs,
but when it comes to write large scale, modularized, extensible
software there are so many things to deal with, that one is
programming more infrastructure than actual worker code.

I was looking for some other languages that would produce native
code and don't rely on special libraries. Among others e.g.
Objective-C I also ran over D a couple of months ago. Now it's
time to put the code snippets together I've developed in the
last years to form a 3D engine. And here come my questions:

=== Binary Modules ===
I played around with D a bit, but so long it just created
standard .o files (no problem there). However for my engine I
created a component system, that already can glue various
scripting languages together, but I failed with exporting C++;
it's just to complicated. One special feature of the component
system is, that it has it's own dynamic loader, that uses it's
own binary format ECM (EVEN Component Module, EVEN is the name
of my engine), being ELF with some add ons, e.g. the custom
format can store not only relocation data and identifiers, but
also metadata and type dependencies. E.g. you you've got a class
foo in module foomod.ecm derived from class bar on barmod.ecs in
foomod.ecs there is stored a dependency on a class bar with a
certain signature. It may also store a link to the module file,
but the default behaviour of ECS is to index all avaliable
modules on startup and load an module with an apropriate class
on demand. If you've deriving classes naturally the exact class
must be matched, but it is also possible to instanciate by
interface. The main reason I'm having my own dynamic linker is,
that I want to use the same binary with different operating
system platforms (of course not CPU), so that only plattform
dependent modules must be provided redundant. As a speciality
ECS allows tagging multimodules, which means a module can
contain multiple implementations, and which one is loaded
depends on the tags it carries, e.g. on which operating system
it is executed.

Well, that's the theory and it works quite well with the pure
procedural exports I did from C and a small subset of C++ by
providing a separate IDL, but I'm in huge trouble with
templates, multiple inheritance. You know what I mean. The
problem is, that a lot of C++ standard types are based around
templates.

In how far is D better suited to create such binary modules? To
create a basic module my module builder/linker needs information
about the exported classes, interfaces, and functions plus their
Metadata.

=== Metadata ===
An important aspect of my component system is, that it chooses
class implementations, interfaces and function on thir
relationship and metadata. Metadata is of which types a value is
of (it also supports generic variant types) and what values an
object carries or a function takes and returns. Can D provide
this metadata on
- runtime
- compile time
?

=== Memory Management ===
As I read D has it's own memory management. Is it possible, that
I replace the builtin memory management with my own?

Please be patient with me, I installed D on my development system
only a few hours ago and need some orientation. Usually I can
need only 2 weeks to learn a new programming language, but
learning requires asking - sometimes dumb - questions.

-- 
Wolfgang Draxinger
Sep 13 2005
parent reply pragma <EricAnderton youknowthedrill.yahoo> writes:
Wolfgang Draxinger wrote:
 I've a long (10 years) experience in C++ programming, but now I'm
 at the point "fed up": I can't take it any more. In my
 experience C++ is nice for self contained, monolithic programs,
 but when it comes to write large scale, modularized, extensible
 software there are so many things to deal with, that one is
 programming more infrastructure than actual worker code.
 
 I was looking for some other languages that would produce native
 code and don't rely on special libraries. Among others e.g.
 Objective-C I also ran over D a couple of months ago. Now it's
 time to put the code snippets together I've developed in the
 last years to form a 3D engine. And here come my questions:
 
 === Binary Modules ===
 I played around with D a bit, but so long it just created
 standard .o files (no problem there). However for my engine I
 created a component system, that already can glue various
 scripting languages together, but I failed with exporting C++;
 it's just to complicated. One special feature of the component
 system is, that it has it's own dynamic loader, that uses it's
 own binary format ECM (EVEN Component Module, EVEN is the name
 of my engine), being ELF with some add ons, e.g. the custom
 format can store not only relocation data and identifiers, but
 also metadata and type dependencies. E.g. you you've got a class
 foo in module foomod.ecm derived from class bar on barmod.ecs in
 foomod.ecs there is stored a dependency on a class bar with a
 certain signature. It may also store a link to the module file,
 but the default behaviour of ECS is to index all avaliable
 modules on startup and load an module with an apropriate class
 on demand. If you've deriving classes naturally the exact class
 must be matched, but it is also possible to instanciate by
 interface. The main reason I'm having my own dynamic linker is,
 that I want to use the same binary with different operating
 system platforms (of course not CPU), so that only plattform
 dependent modules must be provided redundant. As a speciality
 ECS allows tagging multimodules, which means a module can
 contain multiple implementations, and which one is loaded
 depends on the tags it carries, e.g. on which operating system
 it is executed.
 
 Well, that's the theory and it works quite well with the pure
 procedural exports I did from C and a small subset of C++ by
 providing a separate IDL, but I'm in huge trouble with
 templates, multiple inheritance. You know what I mean. The
 problem is, that a lot of C++ standard types are based around
 templates.
 
 In how far is D better suited to create such binary modules? To
 create a basic module my module builder/linker needs information
 about the exported classes, interfaces, and functions plus their
 Metadata.
Wow. You certainly know how to get a developer's attention. :) I'm presently working on a runtime loader and linker architecture for D. http://www.dsource.org/projects/ddl http://www.dsource.org/forums/http://www.dsource.org/forums/viewforum.php?f=70 The theory and goals behind DDL are *frighteningly* close to what you've done with EVEN. Intermediate files in D (.obj files under windows for example) contain the needed symbolic information to determine module-level dependencies. Since modules map one-to-one with D intermediate files, it suits itself very well to runtime loading and linking. DDL presently digests OMF formatted .lib and .obj files. COFF and ELF support are planned for the very near future. DDL also supports its own module type, which is really a header/wrapper for any other supported type; its intended to help make module searches and linking a bit faster as well as provide a hook for versioning and metadata. AFAIK, this project won't have any hangups with resolving templates and the rest since we're merely emulating how the compile-time linker works. Please take a look through the forums for the project and ask me any questions you like. Also, if there's any features of ECN that you think would work well for DDL, please don't hesitate to post about it or contact me personally via email. :) ... but until this project is complete, D is stuck with monolithic builds, shared libraries and dll files.
 
 === Metadata ===
 An important aspect of my component system is, that it chooses
 class implementations, interfaces and function on thir
 relationship and metadata. Metadata is of which types a value is
 of (it also supports generic variant types) and what values an
 object carries or a function takes and returns. Can D provide
 this metadata on
 - runtime
 - compile time
 ?
Presently, only at the module level. D symbols are encoded with namespace and type information intact: For example, the method "char[] foobar(uint[] a)" is exported as the symbol "_D6foobarFAkZAa". Currently, DDL can translate the name-mangling into the readable form, but it does not generate reflection information... yet. D lacks a reflection interface, but here are movements about to bring to the table a solid reccomendation for Walter to implement in the final specification. Also, while we're on the topic, there is no runtime emit interface either (not that it can't be done of course, just that nobody's written it yet).
 
 === Memory Management ===
 As I read D has it's own memory management. Is it possible, that
 I replace the builtin memory management with my own?
Yes. The garbage collector is implemented in the platform library (phobos) itself. Its quite easy to implement changes, provided that a) you know what you're doing and b) you maintain the needed hooks to satisfy the current ABI. However, copying and generational GC's will not work with the current incarnation of D, due to its design.
 Please be patient with me, I installed D on my development system
 only a few hours ago and need some orientation. Usually I can
 need only 2 weeks to learn a new programming language, but
 learning requires asking - sometimes dumb - questions.
Welcome to the fold. -- - EricAnderton at yahoo
Sep 13 2005
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
pragma wrote:
 ...
 However, copying and generational GC's will 
 not work with the current incarnation of D, due to its design.
 
Huh, what is this you say, is it true? If so why? I was under the impression of pretty much the opposite. -- Bruno Medeiros Computer Science/Engineering student
Sep 19 2005
parent reply pragma <EricAnderton youknowthedrill.yahoo> writes:
Bruno Medeiros wrote:
 pragma wrote:
 
 ...
 However, copying and generational GC's will not work with the current 
 incarnation of D, due to its design.
Huh, what is this you say, is it true? If so why? I was under the impression of pretty much the opposite.
Its true. The problem is that with any GC that implements moving of memory blocks (generational, copying or compacting), it needs to be able to work around the fact that D program code currently works in raw memory addresses. Simply moving a block of memory would be disasterous as you'd have to tackle any number of outstanding pointers as well. Now, you could hack this in by modifying the GC to scan everything and rewrite pointers in all managed memory as needed, but there are tons of corner-cases in this strategy. Plus, the GC doesn't really keep track of type information, so there's no way to know if a given dword really contains a pointer or an integer. D is modestly coupled to the conservative nature of mark-sweep, so this normally isn't a problem; so the language would need some way to make feeding this info to the GC transparent. Alternately, one could redefine references as abstract handles to managed memory, which makes the GC an intermediary for just about everything; a strategy that requires additional engineering at the compiler level to work in to D. This would also mean complicating interop with legacy C code, again something that requires more programming (probably just in phobos) to get working. There are probably other approaches out there, but I'd wager that they would all benefit from tweaking D this way or that to work seamlessly. -- - EricAnderton at yahoo
Sep 22 2005
next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
pragma wrote:
 Bruno Medeiros wrote:
 
 pragma wrote:

 ...
 However, copying and generational GC's will not work with the current 
 incarnation of D, due to its design.
Huh, what is this you say, is it true? If so why? I was under the impression of pretty much the opposite.
Hum, are you sure you understood my question? Or maybe I misunderstood your original statement. You said (I think) that with D's design one could not implement a copying/moving (whether compacting, generational, whatever) garbage collector. If this is what you were saying, then I don't understand your reply. The language spec of D, namely the "Garbage Collection" section ( http://www.digitalmars.com/d/garbage.html ), specifies restrictions on pointer usage to allow "maximum flexibility in garbage collector design", in particular copying collectors. It even explicitly mentions them in that page ( "A compacting garbage collector may change this value" , "A copying garbage collector can arbitrarily move objects around in memory, thus ..." ) . Yes, to actually implement one such collector one would need type information, and would also need to change pointer values, but were is the unfeasability in that?
 Its true.  The problem is that with any GC that implements moving of 
 memory blocks (generational, copying or compacting), it needs to be able 
 to work around the fact that D program code currently works in raw 
 memory addresses.  Simply moving a block of memory would be disasterous 
 as you'd have to tackle any number of outstanding pointers as well.
 
Any copying/moving collector (of any supporting language) has that issue, and they deal with it. Why is it a problem for D? What do you mean by "D program code currently works in raw memory addresses." ?
 Now, you could hack this in by modifying the GC to scan everything and 
 rewrite pointers in all managed memory as needed, but there are tons of 
 corner-cases in this strategy.  Plus, the GC doesn't really keep track 
 of type information, so there's no way to know if a given dword really 
 contains a pointer or an integer.  D is modestly coupled to the 
 conservative nature of mark-sweep, so this normally isn't a problem; so 
 the language would need some way to make feeding this info to the GC 
 transparent.
 
The current GC doesn't keep track of type information, but there is no design issue that would impossibilitate (or difficultate) that, much to the contrary. Or is it?.. -- Bruno Medeiros Computer Science/Engineering student
Sep 27 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <dhbvq9$ma8$1 digitaldaemon.com>, Bruno Medeiros says...
pragma wrote:
 Bruno Medeiros wrote:
 
 pragma wrote:

 ...
 However, copying and generational GC's will not work with the current 
 incarnation of D, due to its design.
Huh, what is this you say, is it true? If so why? I was under the impression of pretty much the opposite.
Hum, are you sure you understood my question? Or maybe I misunderstood your original statement.
Okay, I may need to clarify myself a little bit here. :) D's "design" is actually enshrined within the reference implementation (DMD) in addition to what is on the website. Having used D through literally over 50 revisions myself, I'm pretty accustomed to confusing the two. Earlier in this thread, I used the word 'design' in a few spots where 'implementation' (or "D's implementation as DMD") may have been more appropriate. Sorry for the confusion. You're right, it's not unfeasable for *D* (as a language) to use a copying collector, but the current design/implementation simply won't work 100% as well as it does against the current GC due to how code is generated. That was really the main thrust of the point I tried to make earlier.
You said (I think) that with D's design one could not implement a 
copying/moving (whether compacting, generational, whatever) garbage 
collector. If this is what you were saying, then I don't understand your 
reply. The language spec of D, namely the "Garbage Collection" section ( 
http://www.digitalmars.com/d/garbage.html ), specifies restrictions on 
pointer usage to allow "maximum flexibility in garbage collector 
design", in particular copying collectors. It even explicitly mentions 
them in that page ( "A compacting garbage collector may change this 
value" , "A copying garbage collector can arbitrarily move objects 
around in memory, thus ..." ) .
Again, my apologies for the design/implementation thing. As far as I understand, Walter has made many steps to keep the door open for copying/moving GC types; hence the references to copying GC's in the documentation. It has been mentioned in this newsgroup before, it's not 100% ready for a copying/moving GC yet. For example, the toHash() method of Object is presently implemented as using the memory location for the object; it would need to be changed.
Yes, to actually implement one such collector one would need type 
information, and would also need to change pointer values, but were is 
the unfeasability in that?
Its not unfeasable at all, its just that DMD isn't doing this yet, nor is this anywhere in the specification. Again, this is just one of the potential changes to D's design I was referring to. :)
 Its true.  The problem is that with any GC that implements moving of 
 memory blocks (generational, copying or compacting), it needs to be able 
 to work around the fact that D program code currently works in raw 
 memory addresses.  Simply moving a block of memory would be disasterous 
 as you'd have to tackle any number of outstanding pointers as well.
 
Any copying/moving collector (of any supporting language) has that issue, and they deal with it. Why is it a problem for D? What do you mean by "D program code currently works in raw memory addresses." ?
Well, its probably old hat, but new() returns the actual address in memory on the heap just like malloc() does. So, right now, one can expect the following to work: Object foo = cast(Object)cast(void*)(new Object); Nice and easy: new returns a pointer which can be casted about. Regardless of type, that pointer is really the same value. Now, imagine you've changed the underlying implementation of a reference to be a GC handle, rather than a heap memory address like it is now. Now you have a problem: the cast to and from void* no longer has such a simple behavior. Regardless of what path you take from here, you are going to change the behavior/design of the language.
 Now, you could hack this in by modifying the GC to scan everything and 
 rewrite pointers in all managed memory as needed, but there are tons of 
 corner-cases in this strategy.  Plus, the GC doesn't really keep track 
 of type information, so there's no way to know if a given dword really 
 contains a pointer or an integer.  D is modestly coupled to the 
 conservative nature of mark-sweep, so this normally isn't a problem; so 
 the language would need some way to make feeding this info to the GC 
 transparent.
 
The current GC doesn't keep track of type information, but there is no design issue that would impossibilitate (or difficultate) that, much to the contrary. Or is it?..
You're right, there isn't anything that would prevent that. In fact, someone already submitted to the newsgroup here a prototype mark/sweep GC that uses typeinfo hints to increase efficency (basically prevents scans of uint[] arrays and things of that nature). But like everything that would make an efficent and useful copying/moving GC, it's not here yet. I hope this clears up my position. :) Again, I'd don't think a moving/copying GC is impossible for D, but any such solution approached without some changes to the compiler/spec/design is going to be very far removed from optimal, if at all useful. - EricAnderton at yahoo
Sep 27 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <dhc4la$15ee$1 digitaldaemon.com>, pragma says...
Now, imagine you've changed the underlying implementation of a reference to be a
GC handle, rather than a heap memory address like it is now.  Now you have a
problem: the cast to and from void* no longer has such a simple behavior.
Regardless of what path you take from here, you are going to change the
behavior/design of the language.
This is one feature I don't expect to ever change, but that the syntax allows it still worries me. Why do class references omit the pointer qualifer if they are clearly pointers?
I hope this clears up my position. :)  Again, I'd don't think a moving/copying
GC is impossible for D, but any such solution approached without some changes to
the compiler/spec/design is going to be very far removed from optimal, if at all
useful.
I think one issue is that it isn't always clear where to draw the line between established practice and unfinished code when using DMD as a reference. Though that D has an ABI that seems intended to be a part of the standard says a lot--it means fundamental things like whether object references are pointers or handles simply cannot change from implementation to implementation. I think moving GCs are an eventual goal, as they tend to be quite fast, but that's pretty far down the list of priorities. Sean
Sep 27 2005
prev sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
pragma wrote:
 In article <dhbvq9$ma8$1 digitaldaemon.com>, Bruno Medeiros says...
 
pragma wrote:

Bruno Medeiros wrote:


pragma wrote:


...
However, copying and generational GC's will not work with the current 
incarnation of D, due to its design.
Huh, what is this you say, is it true? If so why? I was under the impression of pretty much the opposite.
Hum, are you sure you understood my question? Or maybe I misunderstood your original statement.
Okay, I may need to clarify myself a little bit here. :) D's "design" is actually enshrined within the reference implementation (DMD) in addition to what is on the website. Having used D through literally over 50 revisions myself, I'm pretty accustomed to confusing the two. Earlier in this thread, I used the word 'design' in a few spots where 'implementation' (or "D's implementation as DMD") may have been more appropriate. Sorry for the confusion. You're right, it's not unfeasable for *D* (as a language) to use a copying collector, but the current design/implementation simply won't work 100% as well as it does against the current GC due to how code is generated. That was really the main thrust of the point I tried to make earlier.
You said (I think) that with D's design one could not implement a 
copying/moving (whether compacting, generational, whatever) garbage 
collector. If this is what you were saying, then I don't understand your 
reply. The language spec of D, namely the "Garbage Collection" section ( 
http://www.digitalmars.com/d/garbage.html ), specifies restrictions on 
pointer usage to allow "maximum flexibility in garbage collector 
design", in particular copying collectors. It even explicitly mentions 
them in that page ( "A compacting garbage collector may change this 
value" , "A copying garbage collector can arbitrarily move objects 
around in memory, thus ..." ) .
Again, my apologies for the design/implementation thing. As far as I understand, Walter has made many steps to keep the door open for copying/moving GC types; hence the references to copying GC's in the documentation. It has been mentioned in this newsgroup before, it's not 100% ready for a copying/moving GC yet. For example, the toHash() method of Object is presently implemented as using the memory location for the object; it would need to be changed.
Yes, to actually implement one such collector one would need type 
information, and would also need to change pointer values, but were is 
the unfeasability in that?
Its not unfeasable at all, its just that DMD isn't doing this yet, nor is this anywhere in the specification. Again, this is just one of the potential changes to D's design I was referring to. :)
Its true.  The problem is that with any GC that implements moving of 
memory blocks (generational, copying or compacting), it needs to be able 
to work around the fact that D program code currently works in raw 
memory addresses.  Simply moving a block of memory would be disasterous 
as you'd have to tackle any number of outstanding pointers as well.
Any copying/moving collector (of any supporting language) has that issue, and they deal with it. Why is it a problem for D? What do you mean by "D program code currently works in raw memory addresses." ?
Well, its probably old hat, but new() returns the actual address in memory on the heap just like malloc() does. So, right now, one can expect the following to work: Object foo = cast(Object)cast(void*)(new Object); Nice and easy: new returns a pointer which can be casted about. Regardless of type, that pointer is really the same value. Now, imagine you've changed the underlying implementation of a reference to be a GC handle, rather than a heap memory address like it is now. Now you have a problem: the cast to and from void* no longer has such a simple behavior. Regardless of what path you take from here, you are going to change the behavior/design of the language.
Now, you could hack this in by modifying the GC to scan everything and 
rewrite pointers in all managed memory as needed, but there are tons of 
corner-cases in this strategy.  Plus, the GC doesn't really keep track 
of type information, so there's no way to know if a given dword really 
contains a pointer or an integer.  D is modestly coupled to the 
conservative nature of mark-sweep, so this normally isn't a problem; so 
the language would need some way to make feeding this info to the GC 
transparent.
The current GC doesn't keep track of type information, but there is no design issue that would impossibilitate (or difficultate) that, much to the contrary. Or is it?..
You're right, there isn't anything that would prevent that. In fact, someone already submitted to the newsgroup here a prototype mark/sweep GC that uses typeinfo hints to increase efficency (basically prevents scans of uint[] arrays and things of that nature). But like everything that would make an efficent and useful copying/moving GC, it's not here yet. I hope this clears up my position. :) Again, I'd don't think a moving/copying GC is impossible for D, but any such solution approached without some changes to the compiler/spec/design is going to be very far removed from optimal, if at all useful. - EricAnderton at yahoo
Yes, I understand more clearly now. I would say then that I agree there might be some blurring between the reference implementation and the D language design/spec when the implementation does some things not specified in the D spec. However when the implementation goes against the D spec in some aspect, then there is a bug in either of the two, and I would say that the spec takes precedence by default in terms of correctness. The toHash() issue you mentioned seems such an example of a bug, however (I presume) it's still there because it has yet no ill effects and there are bigger priorities. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Sep 30 2005
prev sibling parent reply Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
pragma wrote:

 Bruno Medeiros wrote:
 pragma wrote:
 
 ...
 However, copying and generational GC's will not work with the
 current incarnation of D, due to its design.
Huh, what is this you say, is it true? If so why? I was under the impression of pretty much the opposite.
Its true. The problem is that with any GC that implements moving of memory blocks (generational, copying or compacting), it needs to be able to work around the fact that D program code currently works in raw memory addresses. Simply moving a block of memory would be disasterous as you'd have to tackle any number of outstanding pointers as well.
 ...
 Alternately, one could redefine references as abstract handles
 to managed memory, which makes the GC an intermediary for just
 about everything; a strategy that requires additional
 engineering at the
 compiler level to work in to D.  This would also mean
 complicating interop with legacy C code, again something that
 requires more programming (probably just in phobos) to get
 working.
The memory management of my component system was designed with a relocation GC in mind, but it can also work with raw memory and offers an interface to smart memory handles, that operate on a address range, separated from the raw heap. But thinking of how this could be put in D. foo a = new foo(); foo c = new foo(); // "a" and "c" are smart handles, not just raw references { foo *b; // "b" is an ordinary pointer to foo in a nested scope b = &a; // By assigning the pointer of "a" to "b", the smart handle "a" // gets locked and can't be relocated anymore, in this scope b = &c; // Now the same for c } // We left the scope of be, so we can unlock the smart handles // "a" and "c" The idea is, that pointers are only valid within their scope. Any object, that get's referenced by a pointer will by locked upon entering the scope in which the pointer resies. After "b" gets out of scope any instance it pointed to gets unlocked. The same goes for annonymous pointers, such as in a void bar(foo *b) { } void some_function() { bar(&a); } In this example a annonymous pointer exists in the scope of "some_function", thus "a" gets locked by entering "some_function" and unlocked upon return. Well, that is just an idea, on how to solve it. The nice thing is, that it won't require much logic, since scope determination is simple and it would only require lock and unlock calls, No reference counting required. Well, just my 2 cents. -- Wolfgang Draxinger
Sep 29 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <dhi5v8$fl7$1 digitaldaemon.com>, Wolfgang Draxinger says...
The memory management of my component system was designed with a
relocation GC in mind, but it can also work with raw memory and
offers an interface to smart memory handles, that operate on a
address range, separated from the raw heap.

But thinking of how this could be put in D.
[snip] Frankly, I think it must be one way or the other in D. I don't want to have to deal with pointers in some instances and handles in another. That just seems like needless complexity for the most part. And it would also be a tad odd to have classes referenced by handles but all other dynamic types referenced by pointers. Using dynamic type info would allow a moving GC to work with pointers as easily as handles anyway. The sticking point for me (as I've mentioned before) is that class references omit the pointer specifier, which I find completely misleading. Even if we never had stack-based classes, it would be nice if the '*' were required for class references, assuming they are guaranteed to be pointers. Sean
Sep 30 2005
parent Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Sean Kelly wrote:

 In article <dhi5v8$fl7$1 digitaldaemon.com>, Wolfgang Draxinger
 says...
The memory management of my component system was designed with
a relocation GC in mind, but it can also work with raw memory
and offers an interface to smart memory handles, that operate
on a address range, separated from the raw heap.

But thinking of how this could be put in D.
[snip] Frankly, I think it must be one way or the other in D. I don't want to have to deal with pointers in some instances and handles in another. That just seems like needless complexity for the most part. And it would also be a tad odd to have classes referenced by handles but all other dynamic types referenced by pointers. Using dynamic type info would allow a moving GC to work with pointers as easily as handles anyway.
Then you however loose interoperability with libraries not moving GC safe. The only thing to prevent this is explicitly locking the memory, which is however error prone, since one could forget this. Such bugs are nasty to track down, because they're difficult to reproduce: you can't predict, that the GC will do the same move with every instance, or at different times of execution.
 The sticking point for 
 me (as I've mentioned before) is that class references omit the
 pointer specifier, which I find completely misleading.  Even if
 we never had stack-based classes, it would be nice if the '*'
 were required for class references, assuming they are
 guaranteed to be pointers. 
That's an argueable point. -- Wolfgang Draxinger
Sep 30 2005