Tomas Lindquist Olsen wrote:
> std.zlib is not doing this correctly.

I should look at that.

> which also makes me think about how to handle this case properly:
> 
> void[] dst = new void[1024];
> dst.length = dst.length + 1024;
> dst.length = dst.length + 1024;
> dst.length = dst.length + 1024;
> dst.length = dst.length + 1024;
> dst.length = dst.length + 1024;
> 
> assuming one of these calls have to relocate how would I be sure that I
> inform the GC properly?

Inform it with the last one.

> A call to the GC in the end would obviously do, but what if you want to
> make sure the GC doesn't scan the array while it's still being resized?

Depends on what data you put in it.

> While I'm at it I have been wondering why we can't have:
> 
> void[1024] sa;
> 
> when
> 
> void[] da = new void[1024];
> 
> is perfectly fine.

You're probably right.

Walter Bright wrote:

> Tomas Lindquist Olsen wrote:
> 
> > which also makes me think about how to handle this case properly:
> > 
> > void[] dst = new void[1024];
> > dst.length = dst.length + 1024;
> > dst.length = dst.length + 1024;
> > dst.length = dst.length + 1024;
> > dst.length = dst.length + 1024;
> > dst.length = dst.length + 1024;
> > 
> > assuming one of these calls have to relocate how would I be sure that I inform the GC properly?
> 
> Inform it with the last one.
> 
> > A call to the GC in the end would obviously do, but what if you want to make sure the GC doesn't scan the array while it's still being resized?
> 
> Depends on what data you put in it.
> 

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.
Just putting the hasNoPointers in the end when no more resizing will
happen is not good enough as the GC could easily be invoked in between
and 'buf' would be scanned.

I guess you could be unlucky and the GC could be triggered (by another
thread) after 'new void[1024]' but before
'std.gc.hasNoPointers(buf.ptr)', in which case there is not much to do.
Is a ubyte[] safe from this problem? (if it even exists)

> > While I'm at it I have been wondering why we can't have:
> > 
> > void[1024] sa;
> > 
> > when
> > 
> > void[] da = new void[1024];
> > 
> > is perfectly fine.
> 
> You're probably right.

Given the new meaning of void arrays, I definitely think it should be reconsidered.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ep6asn$aer$1@digitaldaemon.com...
> 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

It appears that overriding TypeInfo implementations is no longer allowed. Was this intentional?

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.

> Is a ubyte[] safe from this problem? (if it even exists)

ubyte[]s won't get scanned for pointers.

JohnC wrote:
> It appears that overriding TypeInfo implementations is no longer allowed. Was this intentional?

TypeInfo is meant to be generated by the compiler.

The following code stopped working in 1.001. It works fine in 1.00:

void main()
{
	auto rs = std.string.split("a\tb\nc\td\ne\tf","\n");
	assert(rs.length==3);

	foreach(r;rs) {
	    auto f = std.string.split(r,"\t");
	    assert(f.length==2);
	}
}


std.string did not change, so I suspect there's something in the GC :(

L.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ep7b0h$155a$2@digitaldaemon.com...
> JohnC wrote:
>> It appears that overriding TypeInfo implementations is no longer allowed. Was this intentional?
>
> TypeInfo is meant to be generated by the compiler.

I understand that. But it was nice to be able to alter the default behaviour of TypeInfo_Aa, for example, to be locale-aware. That way I could easily get things like the .sort property for string arrays working correctly for languages with diacritics etc.

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

Walter Bright wrote:
> New pointer-aware GC. Should run significantly faster for some programs.

Thank you! I'm sure this will be a tremendous improvement.

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

class C {
    private char[][char[]] data;
    void add(char[] a, char[] b) { data[a] = b; }
}

void main() {
    for (int i = 0; i < 1000; i++) {
        auto c = new C;
        for (int j = 0; j < 1000; j++) {
            c.add("test".dup,"test".dup);
        }
    }
}

It seems the ClassInfo.flags are incorrectly set to 2 when only private data members contain pointers.

/Oskar

JohnC wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:ep7b0h$155a$2@digitaldaemon.com...
>> JohnC wrote:
>>> It appears that overriding TypeInfo implementations is no longer allowed. Was this intentional?
>> TypeInfo is meant to be generated by the compiler.
> 
> I understand that. But it was nice to be able to alter the default behaviour of TypeInfo_Aa, for example, to be locale-aware. That way I could easily get things like the .sort property for string arrays working correctly for languages with diacritics etc. 

How did you alter it?