On 11/11/2012 8:37 PM, Jason House wrote:
> On Nov 11, 2012, at 10:53 PM, Walter Bright <walter@digitalmars.com> wrote:
>
>> On 11/11/2012 6:51 PM, Jason House wrote:
>>> How hard would a D to C++ converter be? I think ABI compatibility would be impossible, but might not be too big of a limitation.
>> There are a lot of subtle differences in meaning that would make it very difficult to get that last few %.
> What items would fall into the last few percent? Would it that subset of D be rendered unusable? Or would it still be a step up from C++? :)
>

C++ doesn't define the order of evaluation of subexpressions, for example.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 11 November 2012 07:28, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
> On Sun, Nov 11, 2012 at 8:26 AM, David Held <dmd@wyntrmute.com> wrote:
>> While writing some unit tests for Dsymbol, I noticed that Dsymbol::toPrettyChars() leaks almost everywhere.  In the simple case where a symbol has no parent, it just returns toChars(), which does not leak (at least I don't think it does).  However, whenever the symbol has a parent (or many), the returned string is composed, which requires that it is allocated dynamically (via mem.malloc()). Even though the caller owns the string, and even though it is called dozens of times, it appears that none of the callers are properly disposing of the result.  Unfortunately, it is a bit messy to do so, because you must free the string *only* if it has a parent, which is a pretty bad implementation leak, IMO.  Here is a place where std::string would have worked nicely. ;)
>>
>> I suspect this has gone unnoticed because A) dmd probably has a relatively
>> small memory footprint to begin with or B) most invokations of
>> toPrettyChars() are during a call to error(), so the compiler is about to
>> quit anyway.  What to do?  Leave it alone?  Try to fix it?  Note that fixing
>> it without changing toPrettyChars() would require adding 2-3 lines of code
>> to almost every call.
>>
>> Dave
>>
>>
>> P.S.  Incidentally, this bug is one that is not easily caught with assertions (where would you place the assert that the string was freed?). Fortunately, it is caught by unit testing; but it could also have been caught by documenting that the caller owns the string.  This is why you really want all 3 approaches to code quality.
>
> DMD as a whole is written for garbage collection. It just so happens that it doesn't use one at the moment, which means a lot of things will leak.
>

Another thing that's on my todo list, scoping out integration of all DFE types into GCC's GType system so that it works with the GCC GC. :-)

So far, the only thing I've heard on the Linux side is strapping the Boehm GC onto the frontend, IIRC the GC in DMD is for Windows only?

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 11/13/2012 4:04 AM, Iain Buclaw wrote:
> So far, the only thing I've heard on the Linux side is strapping the Boehm GC onto the frontend, IIRC the GC in DMD is for Windows only? 

It'll work with the others, too, I just didn't see the point unless it panned out for Windows.

You can try the Boehm one.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Tue, 13 Nov 2012, Walter Bright wrote:

> On 11/13/2012 4:04 AM, Iain Buclaw wrote:
> > So far, the only thing I've heard on the Linux side is strapping the Boehm GC onto the frontend, IIRC the GC in DMD is for Windows only?
> 
> It'll work with the others, too, I just didn't see the point unless it panned out for Windows.
> 
> You can try the Boehm one.

There was a question earlier in this thread (which I didn't save but meant
to respond to) about the impact of the addition of the GC.  From what I
remember, the full dmd/druntime/phobos build and test cycle doubled in
duration.  No one, that I recall, spent any time trying to diagnose or
improve it.  Since we were up against a release, the choice was made to
pull it out until someone does have the time to actually work on it, not
just toss in an experiment.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 11/13/2012 5:05 PM, Brad Roberts wrote:
> There was a question earlier in this thread (which I didn't save but meant to respond to) about the impact of the addition of the GC. From what I remember, the full dmd/druntime/phobos build and test cycle doubled in duration. No one, that I recall, spent any time trying to diagnose or improve it. Since we were up against a release, the choice was made to pull it out until someone does have the time to actually work on it, not just toss in an experiment. _______________________________________________

I agree. I had actually put it in there with the intent to lay the foundation, so that others had at least a working system they could experiment with.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 11/13/2012 5:53 PM, Walter Bright wrote:
>
> On 11/13/2012 5:05 PM, Brad Roberts wrote:
>> There was a question earlier in this thread (which I didn't save but meant to respond to) about the impact of the addition of the GC. From what I remember, the full dmd/druntime/phobos build and test cycle doubled in duration. No one, that I recall, spent any time trying to diagnose or improve it. Since we were up against a release, the choice was made to pull it out until someone does have the time to actually work on it, not just toss in an experiment. _______________________________________________
>
> I agree. I had actually put it in there with the intent to lay the foundation, so that others had at least a working system they could experiment with.

Is it better to pursue the GC route or the smart pointer route?

Dave

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 11/13/2012 11:14 PM, David Held wrote:
> On 11/13/2012 5:53 PM, Walter Bright wrote:
>>
>>
>> I agree. I had actually put it in there with the intent to lay the foundation, so that others had at least a working system they could experiment with.
>
> Is it better to pursue the GC route or the smart pointer route?


Since the GC is already there and works, I'd say it's easier to try that route first. Some simple things I'd do to try and speed it up that are specific to dmd:

1. disable all the threading lock code

2. tune it so it doesn't try to do a collection until more than 1Gb is allocated
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 11/13/2012 11:27 PM, Walter Bright wrote:
> [...]
> Since the GC is already there and works, I'd say it's easier to try that route first. Some simple things I'd do to try and speed it up that are specific to dmd:
>
> 1. disable all the threading lock code
>
> 2. tune it so it doesn't try to do a collection until more than 1Gb is allocated

My understanding is that it's a mark/sweep collector.  Is that correct?  Is it even feasible to implement a copying collector, or does dmd do dirty things with pointers that make that problematic? My understanding of GC is that mark/sweep is better if the number of surviving objects is large relative to the total pool, and copying is better if the number is small.  Does dmd tend to create mostly short-lived or long-lived objects?

Obviously the string table is long-lived, and I assume the symbol table as well.  It seems that most of the rest of the work is more short-lived.  If I'm right, then it probably isn't feasible to make the mark/sweep collector very fast/efficient, because it's spending too much time sweeping.

Of course, the generational model combines the best of both worlds, but somehow, I really doubt that the existing GC is generational. ;)

Dave

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 11/14/2012 12:38 AM, David Held wrote:
> On 11/13/2012 11:27 PM, Walter Bright wrote:
>> [...]
>> Since the GC is already there and works, I'd say it's easier to try that route first. Some simple things I'd do to try and speed it up that are specific to dmd:
>>
>> 1. disable all the threading lock code
>>
>> 2. tune it so it doesn't try to do a collection until more than 1Gb is allocated
>
> My understanding is that it's a mark/sweep collector.  Is that correct?

Yes.

>   Is it even feasible to implement a copying collector, or does dmd do dirty things with pointers that make that problematic?

What makes it problematic is you cannot do a copying collector without having type info for all the references. C compilers do not generate that.

> My understanding of GC is that mark/sweep is better if the number of surviving objects is large relative to the total pool, and copying is better if the number is small.  Does dmd tend to create mostly short-lived or long-lived objects?

I don't really know.

>
> Obviously the string table is long-lived, and I assume the symbol table as well.  It seems that most of the rest of the work is more short-lived.  If I'm right, then it probably isn't feasible to make the mark/sweep collector very fast/efficient, because it's spending too much time sweeping.
>
> Of course, the generational model combines the best of both worlds, but somehow, I really doubt that the existing GC is generational. ;)


It isn't, and neither is the Boehm one.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 14 November 2012 09:49, Walter Bright <walter@digitalmars.com> wrote:
>
> On 11/14/2012 12:38 AM, David Held wrote:
>>
>> My understanding of GC is that mark/sweep is better if the number of surviving objects is large relative to the total pool, and copying is better if the number is small.  Does dmd tend to create mostly short-lived or long-lived objects?
>
>
> I don't really know.

At least, the ones created by const-folding are short-lived, and there
is rather a lot of them. This is extreme for CTFE, which is why CTFE
leaks so much memory.
Though actually I want to stop CTFE from creating mountains of garbage
in the first place.
I don't know how much of the total garbage is from const folding though.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals