View mode: basic / threaded / horizontal-split · Log in · Help
June 13, 2005
GC - the rest (sorry:)
here's the rest of the message. sorry for this...
uint gc_big_killer[1048576];
June 13, 2005
Re: GC - the rest (sorry:)
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
Re: GC - the rest (sorry:)
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
Re: GC - the rest (sorry:)
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
Re: GC - the rest (sorry:)
> 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
Re: GC - the rest (sorry:)
> 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.
Top | Discussion index | About this forum | D home