Thread overview
GC - the rest (sorry:)
Jun 13, 2005
k_mar
Jun 13, 2005
Regan Heath
Jun 13, 2005
k_mar
Jun 13, 2005
Regan Heath
Jun 13, 2005
Vathix
Jun 13, 2005
Ben Hinkle
June 13, 2005
here's the rest of the message. sorry for this...
uint gc_big_killer[1048576];

June 13, 2005
On Mon, 13 Jun 2005 11:24:52 +0000 (UTC), <k_mar@seznam.cz> wrote:
> here's the rest of the message. sorry for this...
> uint gc_big_killer[1048576];

?

I see no more message?

Which brings me to another point, this is the 'announce' NG, typically for announcing things, please post questions to either the 'learn' or main NG.

..listing of D newsgroups..
D (deprecated in favour of digitalmars.D)
D.gnu
digitalmars.D
digitalmars.D.announce
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.learn
digitalmars.empire
DMDScript

Regan
June 13, 2005
In article <opssa3h2ol23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Mon, 13 Jun 2005 11:24:52 +0000 (UTC), <k_mar@seznam.cz> wrote:
>> here's the rest of the message. sorry for this...
>> uint gc_big_killer[1048576];
>
>?
>
>I see no more message?
>
Yes, sorry, I'm having problems posting the rest... maybe some illegal
character?
// assuming the page size is 4kB
for (uint i=0; i<1048576; i++) gc_big_killer[i]=(i<<12)+2048;
>
>Which brings me to another point, this is the 'announce' NG, typically for announcing things, please post questions to either the 'learn' or main NG.
>
>..listing of D newsgroups..
>D (deprecated in favour of digitalmars.D)
>D.gnu
>digitalmars.D
>digitalmars.D.announce
>digitalmars.D.bugs
>digitalmars.D.dtl
>digitalmars.D.learn
>digitalmars.empire
>DMDScript
>
>Regan

ok, I admit. and apologize. this is not the right one for my question, sorry to bother you. just thought that the current GC is a MUCH bigger problem than anyone may think and that it should be rewritten as soon as possible for it simply isn't adequate. actually it's the ONLY part where D still didn't convince me that GC is better than "manual" allocation. Of course, GC would be better in the case that it'd work as expected in ALL cases (like JAVA VM which actually only scans pointers because there's no pointer support in JAVA? am I wrong?). I was just curious because D looks soooo promising...

MaR

MaR
June 13, 2005
On Mon, 13 Jun 2005 12:09:08 +0000 (UTC), <k_mar@seznam.cz> wrote:
> In article <opssa3h2ol23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>> On Mon, 13 Jun 2005 11:24:52 +0000 (UTC), <k_mar@seznam.cz> wrote:
>>> here's the rest of the message. sorry for this...
>>> uint gc_big_killer[1048576];
>>
>> ?
>>
>> I see no more message?
>>
> Yes, sorry, I'm having problems posting the rest... maybe some illegal
> character?
> // assuming the page size is 4kB
> for (uint i=0; i<1048576; i++) gc_big_killer[i]=(i<<12)+2048;

This:

uint gc_big_killer[1048576] = void;
for (uint i=0; i<1048576; i++) gc_big_killer[i]=(i<<12)+2048;

will prevent the auto init of the array with zeroes.

I'm not sure, but can the GC function 'removeRange' then be used on the new (messy, might look like pointers) data? I've never used it, and am not sure what it's purpose is. It seems that it would be used here, maybe. Someone else might have some idea.

>> Which brings me to another point, this is the 'announce' NG, typically for
>> announcing things, please post questions to either the 'learn' or main NG.
>>
>> ..listing of D newsgroups..
>> D (deprecated in favour of digitalmars.D)
>> D.gnu
>> digitalmars.D
>> digitalmars.D.announce
>> digitalmars.D.bugs
>> digitalmars.D.dtl
>> digitalmars.D.learn
>> digitalmars.empire
>> DMDScript
>>
>> Regan
>
> ok, I admit. and apologize. this is not the right one for my question, sorry to
> bother you.

No worries, just trying to be neat and tidy.

> just thought that the current GC is a MUCH bigger problem than
> anyone may think and that it should be rewritten as soon as possible for it
> simply isn't adequate.

Well, as I mentioned the impression I get is that the current GC *is* adequate for this stage in D's development, such that other tasks are simply more important. That said, I am sure Walter will be more than happy to entertain any GC implementation you fire his way.

> actually it's the ONLY part where D still didn't convince
> me that GC is better than "manual" allocation. Of course, GC would be better in
> the case that it'd work as expected in ALL cases

It does work as expected in ALL cases.. depending of course on your expectations. Perhaps you should tell us what you expected and what you're seeing, then we can each voice an opinion about what needs to be done about it.

> (like JAVA VM which actually
> only scans pointers because there's no pointer support in JAVA? am I wrong?).

I've no idea :)

> I
> was just curious because D looks soooo promising...

I agree.

Regan
June 13, 2005
> uint gc_big_killer[1048576] = void;
> for (uint i=0; i<1048576; i++) gc_big_killer[i]=(i<<12)+2048;
>
> will prevent the auto init of the array with zeroes.
>
> I'm not sure, but can the GC function 'removeRange' then be used on the new (messy, might look like pointers) data? I've never used it, and am not sure what it's purpose is. It seems that it would be used here, maybe. Someone else might have some idea.

I think the stack is always scanned and removeRange only works on the exact pointer that was added, which you don't know if 'new' provides you with that. Best fix would be to use malloc() memory.
I think it's important to always have the GC in mind when coding, in any language and GC.
June 13, 2005
> ok, I admit. and apologize. this is not the right one for my question,
> sorry to
> bother you. just thought that the current GC is a MUCH bigger problem than
> anyone may think and that it should be rewritten as soon as possible for
> it
> simply isn't adequate.

In what way is it inadequate? Do you mean performance? How did you measure performance? If you mean it is inadequate because of ambiguous pointers then no rewrite will be able to avoid that since it is part of the language.

> actually it's the ONLY part where D still didn't convince
> me that GC is better than "manual" allocation. Of course, GC would be
> better in
> the case that it'd work as expected in ALL cases (like JAVA VM which
> actually
> only scans pointers because there's no pointer support in JAVA? am I
> wrong?). I
> was just curious because D looks soooo promising...

Java doesn't have the ambiguous pointer problem, if that's what you mean.