Oskar Linde wrote:
> Unfortunately, the new GC results in segfaults for me. I was lucky to track it down and generate a small test case:

This is good. I'll try to get a fix out very soon.

On Wed, 24 Jan 2007 11:30:33 -0500, renoX <renosky@free.fr> wrote:

> Chris Miller Wrote:
>> On Wed, 24 Jan 2007 07:01:55 -0500, Georg Wrede <georg@nospam.org> wrote:
>>
>> > Oskar Linde wrote:
>> >> Walter Bright wrote:
>> >>
>> >>> New pointer-aware GC.
>> >>  Unfortunately, the new GC results in segfaults for me.
>> >
>> > If one of the motives for a 1.0 release was to remove obstacles for
>> > using D in for-profit programming, the above quote blows it away.
>> >
>> > What the Real User (as opposed to us, groupies, DIYs or academics)
>> > needs, is a surefire way to recognize which release to use for his
>> > paying customers!
>> >
>> > This could be as simple as dividing the Change Log page into Stable  
>> and
>> > Unstable releases. And/or deciding on a numbering scheme. Or  
>> something.
>>
>> Agreed! Perhaps the "D 1.0" should be a fork that only includes fixes.
>
> But the modification of the GC is a fix: after all in the old GC, there are some programs which can slow down a lot the GC which I consider to be a design bug/limitation.
>
> IMHO the default GC should be a good 'all around' GC, not necessarily the highest performance but it should not have easy to trigger pathological cases or too long pause duration which would make it unsuitable for client application (and this will be quite hard to do for multicore PC).
>
> Of course fixing a GC is a high-risk operation, but cautious users can wait a few weeks before using a new version of the compiler, checking if there is a big regression before updating.

Yep, too risky. It's not a fix if it causes more problems. It was untested.

>
>> Also, D and DMD seem to be used interchangeably; there should be a
>> distinction. Not all D implementations have everything DMD has. e.g.
>> "What's New for D 1.0" (changelog)... well that looks like a list for
>> what's new in DMD, not D the language. Not all compilers have these issues
>> and features and follow all the same formats (this type of linker, that
>> particular implementation of a function, OMF object files, etc).
>
> Well DMD is the 'reference implementation' of D, so that's not too surprising that both are used interchangeably..

I know, and that doesn't invalidate what I said; they're not the same thing. It's not JUST a reference; if it is, D sucks, GDC is not a valid D implementation, and there's really no way to have another implementation.

Walter Bright wrote:
> New pointer-aware GC. Should run significantly faster for some programs.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.1.001.zip

Great to see the progress. Though, seems like you got some petty "beta" tester, huh? *g

Georg Wrede wrote:
> Oskar Linde wrote:
>> Walter Bright wrote:
>>
>>> New pointer-aware GC.
>>
>> Unfortunately, the new GC results in segfaults for me.
> 
> If one of the motives for a 1.0 release was to remove obstacles for using D in for-profit programming, the above quote blows it away.
> 
> 
> What the Real User (as opposed to us, groupies, DIYs or academics) needs, is a surefire way to recognize which release to use for his paying customers!
> 
> This could be as simple as dividing the Change Log page into Stable and Unstable releases. And/or deciding on a numbering scheme. Or something.

I wonder if it actually should be decided by Walter at all? You never know for sure if a release is truly stable until it's been exercised a bit. DStress seems like a good start; if there are any regressions, it's clearly not a stable release. And the more tests get added to it, the more confidence we can have in it.

Frits van Bommel wrote:

> Walter Bright wrote:
> > Tomas Lindquist Olsen wrote:
> > > Let me clarify what I mean. Consider this code:
> > > 
> > > import std.gc;
> > > 
> > > void test()
> > > {
> >>    void[] buf = new void[1024];
> >>    std.gc.hasNoPointers(ret.ptr);
> >>    // invoking gc will not scan buf. ok
> >>    buf.length = buf.length*2;
> >>    // could invoking gc now potentially scan buf?
> > > }
> > > 
> > > I'm thinking how to make sure a void[] is never scanned.
> > > A somewhat realistic case for this would be (again) the
> > > std.file.read function.
> > > If we append some data to this buffer will the GC be smart enough
> > > to know it still holds no pointers? That is even with the
> > > reallocation and potential relocation.
> > 
> > It'll reallocate based on the type of buf, which is void[], so you'll  need to invoke gc.hasNoPointers again.
> 
> Shouldn't it copy pointer-ness from the original to the new array? That seems like the logical thing to do.  The same applies to concatenating arrays, though perhaps that should follow the rule "the new array contains pointers if either original array contained pointers".

This is what I'm thinking as well. Just dropping the information is not acceptable IMHO. It means that you have to call hasNoPointers every time you resize a void[] to be sure the GC is handling it like you indended.

Tomas Lindquist Olsen wrote:
> Frits van Bommel wrote:
> 
>> Walter Bright wrote:
>>> Tomas Lindquist Olsen wrote:
>>>> Let me clarify what I mean. Consider this code:
>>>>
>>>> import std.gc;
>>>>
>>>> void test()
>>>> {
>>>>    void[] buf = new void[1024];
>>>>    std.gc.hasNoPointers(ret.ptr);
>>>>    // invoking gc will not scan buf. ok
>>>>    buf.length = buf.length*2;
>>>>    // could invoking gc now potentially scan buf?
>>>> }
>>>>
>>>> I'm thinking how to make sure a void[] is never scanned.
>>>> A somewhat realistic case for this would be (again) the
>>>> std.file.read function.
>>>> If we append some data to this buffer will the GC be smart enough
>>>> to know it still holds no pointers? That is even with the
>>>> reallocation and potential relocation.
>>> It'll reallocate based on the type of buf, which is void[], so
>>> you'll  need to invoke gc.hasNoPointers again.
>> Shouldn't it copy pointer-ness from the original to the new array?
>> That seems like the logical thing to do.  The same applies to
>> concatenating arrays, though perhaps that should follow the rule "the
>> new array contains pointers if either original array contained
>> pointers".
> 
> This is what I'm thinking as well. Just dropping the information is not
> acceptable IMHO. It means that you have to call hasNoPointers every
> time you resize a void[] to be sure the GC is handling it like you
> indended.

I've been mulling this over the past few weeks, and even went so far as to begin a patch to do this, but I'm undecided.  First, it could work one of two ways: either it could be made to only affect resizing of the original array itself, or it could be made to affect resizing of that array and any slices of that array.  The latter behavior seems to make the most sense from a consistency perspective, but I worry that making such an attribute "viral" could result in unpredictable behavior in large applications where slices are passed into contexts which may be unaware of the slice's origin.  For the moment, I've decided to wait and see how much of an issue this turns out to be, and I'll probably finish the GC mods to support it efficiently just in case.


Sean

On Thu, 25 Jan 2007 10:23:27 +0300, Don Clugston <dac@nospam.com.au> wrote:

> I wonder if it actually should be decided by Walter at all? You never know for sure if a release is truly stable until it's been exercised a bit.

I agree.

May be it is a good idea to use scheme with 'release candidates' for new stable versions? For example, when the next stable version (1.003) is ready to go out it will be published as 1.003-rc1. Then, if in a week or two nobody informs about any critical bug (like in the history with 1.001) 1.003-rc1 republished as 1.003 (final stable). If some bug found then it fixed and new release candidate, 1.003-rc2 published and so on.

-- 
Regards,
Yauheni Akhotnikau