> First, you should understand that the GC does not know what data is in a
> memory
block.
That is exactly why I was wondering how it figures things out. :)
> Data *allocated* as a void[] (which I highly recommend *not* doing) will be
conservatively marked as containing pointers.
Ah, all right
On Fri, 07 Jan 2011 16:39:20 -0500, %u wrote:
None what so ever.
Huh.. then what about what is said in this link?
http://d.puremagic.com/issues/show_bug.cgi?id=5326#c1
I was told that void[] could contain references, but that ubyte[] would
not, and
that the GC would need to scan the former
> None what so ever.
Huh.. then what about what is said in this link?
http://d.puremagic.com/issues/show_bug.cgi?id=5326#c1
I was told that void[] could contain references, but that ubyte[] would not, and
that the GC would need to scan the former but not the latter. Is that wrong?
Thank you!
%u wrote:
You have to add it to the garbage collector's list of roots
But if I need to do that, then what would be the difference between
void[] and
ubyte[]?
None what so ever. If you want to mark some memory with special bits,
use setattr in core.memory.
--
Simen
> Kinda sorta. I haven't had any problems from that. If you allocate very large
blocks in the garbage collector you may face trouble :-)
Haha okay, thanks. :) (This makes me shiver quite a bit...)
> You have to add it to the garbage collector's list of roots
But if I need to do that, then what
On 01/07/2011 06:47 PM, %u wrote:
It assumes everything on the stack is pointers, at the moment, I believe
Uh-oh... not the answer I wanted to hear, but I was half-expecting this.
So doesn't that mean that, at the moment, D will leak memory?
Kinda sorta. I haven't had any problems from that.
> It assumes everything on the stack is pointers, at the moment, I believe
Uh-oh... not the answer I wanted to hear, but I was half-expecting this.
So doesn't that mean that, at the moment, D will leak memory?
> If it's not on the garbage collected heap, it won't scan it unless you
tell it to.
B
%u wrote:
> Hi,
>
> There's a question that's been lurking in the back of my mind ever since I
> learned about D:
>
> How does the GC distinguish code from data when determining the objects to
> collect? (E.g. void[] from uint[], size_t from void*, etc.?)
>
> If I have a large uint[], it's pract
On 01/06/2011 07:31 AM, %u wrote:
If you have allocated a large uint[], most likely =C3=ACt will be flagged
NO_SCAN, meaning it has no pointers in it, and the GC will ignore it.
Ah, but the trouble is, no one said that this array has to be in the GC heap! I
could easily have a void[] and a uin
> If you have allocated a large uint[], most likely =C3=ACt will be flagged
NO_SCAN, meaning it has no pointers in it, and the GC will ignore it.
Ah, but the trouble is, no one said that this array has to be in the GC heap! I
could easily have a void[] and a uint[] that both point to non-GC manag
On Wed, 05 Jan 2011 16:56:47 -0500, Simen kjaeraas
wrote:
%u wrote:
If I have a large uint[], it's practically guaranteed to have data that
looks like pointers, and that might cause memory leaks.
If you have allocated a large uint[], most likely ìt will be flagged
NO_SCAN, meaning it ha
%u wrote:
Hi,
There's a question that's been lurking in the back of my mind ever since
I learned about D:
How does the GC distinguish code from data when determining the objects
to collect? (E.g. void[] from uint[], size_t from void*, etc.?)
This is hardly the code/data dualism (data c
Hi,
There's a question that's been lurking in the back of my mind ever since I
learned about D:
How does the GC distinguish code from data when determining the objects to
collect? (E.g. void[] from uint[], size_t from void*, etc.?)
If I have a large uint[], it's practically guaranteed to have da
13 matches
Mail list logo
