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