Community

Tony:
> Avoiding yet another black box for one thing.
Yes, that's a real problem. In practice to program effectively in D1 you have to read the source code of the GC (or use lot of documentation about the Phobos GC, but it's absent still).
Bye,
bearophile

Tony wrote:
> "Nick Sabalausky" <a@a.a> wrote in message
> news:gergn9$109b$1@digitalmars.com...
>> "Tony" <tonytech08@gmail.com> wrote in message
>> news:gerdem$rc4$1@digitalmars.com...
>>> "Nick Sabalausky" <a@a.a> wrote in message
>>> news:gep0ej$232$1@digitalmars.com...
>>>> "Tony" <tonytech08@gmail.com> wrote in message
>>>> news:geogvj$1p5r$2@digitalmars.com...
>>>>> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message
>>>>> news:geo5p6$12gk$1@digitalmars.com...
>>>>>> Tony wrote:
>>>>>>> (one HAS to use GC with D, right?)
>>>>>> No. Well, the compiler generates calls to allocate & free memory, but
>>>>>> you can replace those calls with whatever you want. See Tango's
>>>>>> (druntime's) "stub" GC, which just reroutes compiler-generated calls
>>>>>> to GC methods to malloc() and free(). You can implement your own "GC"
>>>>>> or whatever management scheme you want (in fact, if you're writing,
>>>>>> say, a device driver in D, you would want to use a custom allocator
>>>>>> like this and not the built-in GC).
>>>>> Please clarify for me the mem mgmt of D: is the garbage collector
>>>>> optional or not?
>>>> Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but
>>>> it's perfectly doable. I did it a few years ago when I was playing
>>>> around with using GDC with DevKitARM for GBA.
>>>>
>>>> IIRC, you just go into "extern (C) int main(size_t argc, char **argv)"
>>>> in the internal portion of phobos/tango/druntime or wherever it lives
>>>> now and comment-out the calls to "gc_init()" and "gc_term()". You might
>>>> also need to call "gc.disable()" or something (don't really remember).
>>>> And then if you still want to use "new" and/or "delete" with your own
>>>> memory manager, you can use D's class allocator and deallocator feature
>>>> (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you
>>>> could probably plug those class allocators/deallocators directly into
>>>> the internal object class if you wanted.
>>> It sounds like a lot of work and new stuff to learn about the
>>> implementation. Let's face it, I'm not going to use D since it doesn't
>>> offer me anything over C++ that I want. The main thing I may like about D
>>> is that it makes the effort to make implementation of the language
>>> easier, and that, I think, is very key. I am here to look for features I
>>> would put in a new language, though that may be too large of an endeavor
>>> for someone my age.
>>>
>>> Tony
>>>
>> If you've already got your own full-fleged, reliable, memory management
>> system, plugging it into D via the methods Robert and I pointed out is
>> nothing by comparison.
>
> If I could do something with the object model, and or if the compiler is
> open source, I would maybe look at the implementation as a potential
> starting point or learning tool. Every time I've considered using existing
> code though, I have ended up just starting with a clean slate for a number
> of reasons. For now, I'm going to evolve my framework a bit more and produce
> some programs. I'm keeping away from "advanced features" of existing
> languages as much as possible so as not to be tied to them. So far I've not
> found problem doing that. Error handling is the worst beast that I don't
> have completely slain yet. Generics and mem mgmt I have under control. I
> feel a bit limited by existing languages object models, that's probably the
> key reason why I'd like to invent a new language, be it for my own use or
> for more widespread use. Having full control of a language and it's
> implementation is nothing to sneeze at either, but taking advantage of that
> probably takes quite a bit of labor (more than one developer).
>
> Tony
>
>
What exactly is your memory management system? Is it a GC? Is it pooling
code? Is it a more efficient implementation of free/malloc?
--
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

"Bruno Medeiros" <brunodomedeiros+spam@com.gmail> wrote in message
news:gf2967$opv$1@digitalmars.com...
> Tony wrote:
>> "Nick Sabalausky" <a@a.a> wrote in message
>> news:gergn9$109b$1@digitalmars.com...
>>> "Tony" <tonytech08@gmail.com> wrote in message
>>> news:gerdem$rc4$1@digitalmars.com...
>>>> "Nick Sabalausky" <a@a.a> wrote in message
>>>> news:gep0ej$232$1@digitalmars.com...
>>>>> "Tony" <tonytech08@gmail.com> wrote in message
>>>>> news:geogvj$1p5r$2@digitalmars.com...
>>>>>> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message
>>>>>> news:geo5p6$12gk$1@digitalmars.com...
>>>>>>> Tony wrote:
>>>>>>>> (one HAS to use GC with D, right?)
>>>>>>> No. Well, the compiler generates calls to allocate & free memory,
>>>>>>> but you can replace those calls with whatever you want. See Tango's
>>>>>>> (druntime's) "stub" GC, which just reroutes compiler-generated calls
>>>>>>> to GC methods to malloc() and free(). You can implement your own
>>>>>>> "GC" or whatever management scheme you want (in fact, if you're
>>>>>>> writing, say, a device driver in D, you would want to use a custom
>>>>>>> allocator like this and not the built-in GC).
>>>>>> Please clarify for me the mem mgmt of D: is the garbage collector
>>>>>> optional or not?
>>>>> Yes, it can be ripped out, replaced, whatever. It's slightly hacky,
>>>>> but it's perfectly doable. I did it a few years ago when I was playing
>>>>> around with using GDC with DevKitARM for GBA.
>>>>>
>>>>> IIRC, you just go into "extern (C) int main(size_t argc, char **argv)"
>>>>> in the internal portion of phobos/tango/druntime or wherever it lives
>>>>> now and comment-out the calls to "gc_init()" and "gc_term()". You
>>>>> might also need to call "gc.disable()" or something (don't really
>>>>> remember). And then if you still want to use "new" and/or "delete"
>>>>> with your own memory manager, you can use D's class allocator and
>>>>> deallocator feature
>>>>> (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you
>>>>> could probably plug those class allocators/deallocators directly into
>>>>> the internal object class if you wanted.
>>>> It sounds like a lot of work and new stuff to learn about the
>>>> implementation. Let's face it, I'm not going to use D since it doesn't
>>>> offer me anything over C++ that I want. The main thing I may like about
>>>> D is that it makes the effort to make implementation of the language
>>>> easier, and that, I think, is very key. I am here to look for features
>>>> I would put in a new language, though that may be too large of an
>>>> endeavor for someone my age.
>>>>
>>>> Tony
>>>>
>>> If you've already got your own full-fleged, reliable, memory management
>>> system, plugging it into D via the methods Robert and I pointed out is
>>> nothing by comparison.
>>
>> If I could do something with the object model, and or if the compiler is
>> open source, I would maybe look at the implementation as a potential
>> starting point or learning tool. Every time I've considered using
>> existing code though, I have ended up just starting with a clean slate
>> for a number of reasons. For now, I'm going to evolve my framework a bit
>> more and produce some programs. I'm keeping away from "advanced features"
>> of existing languages as much as possible so as not to be tied to them.
>> So far I've not found problem doing that. Error handling is the worst
>> beast that I don't have completely slain yet. Generics and mem mgmt I
>> have under control. I feel a bit limited by existing languages object
>> models, that's probably the key reason why I'd like to invent a new
>> language, be it for my own use or for more widespread use. Having full
>> control of a language and it's implementation is nothing to sneeze at
>> either, but taking advantage of that probably takes quite a bit of labor
>> (more than one developer).
>>
>> Tony
>
> What exactly is your memory management system? Is it a GC? Is it pooling
> code? Is it a more efficient implementation of free/malloc?
I can't disclose those details, sorry.
Tony

Tony wrote:
> I can't disclose those details, sorry.
Either you're working for DoD, or you're trolling. If the entire point
of your code were memory management, you would have said that, most
likely, and would have no interest in D, unless you could base its
garbage collector on your memory management system.
I can't fathom your purpose in posting here. You ask us for what D does
better than C++ and immediately say that none of it applies to you, and
imply that it's not worthwhile. D isn't the language for you. You've
established that. Why are you still here?

Tony wrote:
> Please clarify for me the mem mgmt of D: is the garbage collector optional
> or not? Just allowing me to replace "getmorecore()" or something like that
> and then having the collector on top of that is unacceptable to me. I think
> you may be saying that dynamic memory is in every program, which again is
> not acceptable to me.
You can pretty much avoid all gc in D by doing your allocations using
malloc/free and overloading operators new and delete for your classes.
Some language features rely on gc, like dynamic closures, array
concatenation, and the built-in associative arrays, but those features
need not be used.
> Really, memory control is a key issue when choosing a language for me
> anyway. I require that level of closeness to the hardware. Anything less is
> too 4GL-like for me.
I understand how you feel. For a very long time, I felt the same way. I
wanted the control. I thought GC was for below average programmers who
couldn't handle memory allocation. I worked with a Java implementation
for a while when Java first came out (building a native Java compiler)
and came to realize the basis of my beliefs were unfounded.
GC has some compelling advantages:
1. GC programs can be faster
2. GC programs can use less memory
3. GC programs can be guaranteed to be memory safe
4. GC programs are faster to develop and have fewer bugs

Walter Bright wrote:
> I understand how you feel. For a very long time, I felt the same way. I
> wanted the control. I thought GC was for below average programmers who
> couldn't handle memory allocation. I worked with a Java implementation
> for a while when Java first came out (building a native Java compiler)
> and came to realize the basis of my beliefs were unfounded.
I feel obliged to mention Kris's presentation on garbage collection,
"Array Slicing Fo' Shizzle" (
http://www.authorstream.com/Presentation/george-38229-Kris-Array-Slicing-foShizzle-Background-Java-Enigma-GC-Pressure-slic-Education-ppt-powerpoint/
), mentions some issues with abusing a garbage collector. (Where are the
videos for that? I thought they were released, but I don't see any links
in the likely places.)

Hello Christopher,
> Walter Bright wrote:
>
>> I understand how you feel. For a very long time, I felt the same way.
>> I wanted the control. I thought GC was for below average programmers
>> who couldn't handle memory allocation. I worked with a Java
>> implementation for a while when Java first came out (building a
>> native Java compiler) and came to realize the basis of my beliefs
>> were unfounded.
>>
> I feel obliged to mention Kris's presentation on garbage collection,
> "Array Slicing Fo' Shizzle" (
> http://www.authorstream.com/Presentation/george-38229-Kris-Array-Slici
> ng-foShizzle-Background-Java-Enigma-GC-Pressure-slic-Education-ppt-pow
> erpoint/ ), mentions some issues with abusing a garbage collector.
> (Where are the videos for that? I thought they were released, but I
> don't see any links in the likely places.)
>
http://video.google.com/videoplay?docid=-4010965350602541568&hl=en
The link is provided from this page:
http://d.puremagic.com/conference2007/speakers.html
I haven't actually watched any of these yet since I'm still on dialup. :P
But I see that they can be downloaded as a mp4 file, so maybe I'll have
a go at it.
-JJR

"Walter Bright" <newshound1@digitalmars.com> wrote in message
news:gf5r4l$2kt9$1@digitalmars.com...
> Tony wrote:
>> Please clarify for me the mem mgmt of D: is the garbage collector
>> optional or not? Just allowing me to replace "getmorecore()" or something
>> like that and then having the collector on top of that is unacceptable to
>> me. I think you may be saying that dynamic memory is in every program,
>> which again is not acceptable to me.
>
> You can pretty much avoid all gc in D by doing your allocations using
> malloc/free and overloading operators new and delete for your classes.
> Some language features rely on gc, like dynamic closures, array
> concatenation, and the built-in associative arrays, but those features
> need not be used.
>
>
>> Really, memory control is a key issue when choosing a language for me
>> anyway. I require that level of closeness to the hardware. Anything less
>> is too 4GL-like for me.
>
> I understand how you feel. For a very long time, I felt the same way. I
> wanted the control. I thought GC was for below average programmers who
> couldn't handle memory allocation. I worked with a Java implementation for
> a while when Java first came out (building a native Java compiler) and
> came to realize the basis of my beliefs were unfounded.
>
> GC has some compelling advantages:
To you and a bunch of others it does, you mean. "Compelling", to me, means
something like "leapfrogs enough other issues or capabilities and/or in a
nicer way" than what is currently available or what can be created.
>
> 1. GC programs can be faster
>
> 2. GC programs can use less memory
>
> 3. GC programs can be guaranteed to be memory safe
>
> 4. GC programs are faster to develop and have fewer bugs
None of which "sell me" on GC. But please don't "go there"! (I know that "to
GC or not to GC" is a flamewar topic). Who knows, maybe my own memory
management architecture (the reworked (new and improved! literally) version
not yet in production, but soon) will evolve to be the backend to a garbage
collector. As an independent developer, I have to keep my cards close to my
chest about some of (one?) the reasons why I thing "my way" is compelling
(in the true sense of the word). Gar bage collectors have a (some?)
characteristic(s) that may indeed be deal breakers for some (a lot?) of
software. That's why I think GC should be an opt-in rather than an opt-out
choice. That's a key characteristic of C++: opt-in. And I really, really
like that level of creative freedom. (Of course, in my own language, I'll do
that even better than C++ does. :) Which is not to say though that I expect
to replace C++. My language will be "higher level" (whatever that means)
than C++).
Tony

"Tony" <tonytech08@gmail.com> wrote in message
news:gflkav$8rc$1@digitalmars.com...
>
> "Walter Bright" <newshound1@digitalmars.com> wrote in message
> news:gf5r4l$2kt9$1@digitalmars.com...
>>
>> 1. GC programs can be faster
>>
>> 2. GC programs can use less memory
>>
>> 3. GC programs can be guaranteed to be memory safe
>>
>> 4. GC programs are faster to develop and have fewer bugs
>
> None of which "sell me" on GC.
Why not? They sound like pretty darn good reasons to me. What are you
expecting out of a memory manager, the secret of the universe?
If you have reason to disagree that the items on that list are true, then
ok, I can understand. But if you're saying that those aren't good enough
reasons, then it sounds like you have unrealistic expectations.
> As an independent developer, I have to keep my cards close to my chest
> about some of (one?) the reasons why I thing "my way" is compelling (in
> the true sense of the word).
I'm an independent developer too, but I have to say, this is a clear
indication that your system isn't nearly as special as you think it is.
There are only three types of people who ever have a non-standard solution
and think it's actually worth bothering with such secrecy: 1.
Industry-renowned full-time tech researchers who actually do create good
stuff (and then make it publicly known by the time their research is done),
2. Suits and managers, who don't know a damn thing about the technical side
of anything, including code, and 3. Novices.
I'm not saying this to try to convince you to tell us, or to insult you, but
as a cautionary tale. You need to take a good hard look at your system, be
as objective as you can possibly be, and make sure it really is the that
special. Because anytime you tell yourself "This is so good that nobody else
has thought of it and it's the ace up my sleeve", that should raise a giant
red flag in your mind saying that no, in fact, it's extremely doubtful that
it's anything special at all.

Tony wrote:
> That's why I think GC should be an opt-in rather than an opt-out
> choice. That's a key characteristic of C++: opt-in. And I really, really
> like that level of creative freedom.
I've used a GC with C++ (both the Boehm one and one I wrote myself). The
idea that GC is opt-in in C++ is ok for the user, but not for the
library writer. The poor library writer, faced with supporting both GC
and explicit allocation, winds up stuck with the worst of both. The
problem is when calling new, you cannot tell which you're getting. That
just throws a monkey wrench into designing portable software, because to
effectively use GC entails writing code in a different way.