www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - GC - the rest (sorry:)

reply k_mar seznam.cz writes:
here's the rest of the message. sorry for this...
uint gc_big_killer[1048576];
Jun 13 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jun 13 2005
parent reply k_mar seznam.cz writes:
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
Jun 13 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jun 13 2005
parent Vathix <vathix dprogramming.com> writes:
 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.
Jun 13 2005
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 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.
Jun 13 2005