[Issue 7095] GC doesn't return or reuse unused memory [D2.056]

2011-12-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7095


David Simcha dsim...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dsim...@yahoo.com
 Resolution||INVALID


--- Comment #1 from David Simcha dsim...@yahoo.com 2011-12-11 09:47:56 PST ---
D's GC isn't fully precise yet.  In other words, it can't always tell the
difference between a pointer and a non-pointer.  When you allocate an
80-megabyte array, the probability that some non-pointer will look like it
points into the array if interpreted as a pointer is pretty high.  

This is a fundamental limitation of the current garbage collector design,
rather than a bug.  As a workaround, it's best to use C's malloc for very large
arrays.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7095] GC doesn't return or reuse unused memory [D2.056]

2011-12-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7095



--- Comment #2 from Heywood Floyd soul...@gmail.com 2011-12-11 10:01:25 PST 
---
I understand. Thanks for the reply!

(With risk of polluting the bug tracker here, but perhaps to clarify the
workaround: Could GC.malloc/free be used as well? Also, I assume if a large
array of structs that in turn contain references to other heap objects, those
would not get scanned had the array been C-alloced risking active objects to
get collected?)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7095] GC doesn't return or reuse unused memory [D2.056]

2011-12-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7095



--- Comment #3 from David Simcha dsim...@yahoo.com 2011-12-11 10:12:27 PST ---
(In reply to comment #2)
 I understand. Thanks for the reply!
 
 (With risk of polluting the bug tracker here, but perhaps to clarify the
 workaround: Could GC.malloc/free be used as well? 

You could use GC.free().  It's somewhat dangerous, though, because you risk
corrupting the GC if you free something incorrectly.  

 Also, I assume if a large
 array of structs that in turn contain references to other heap objects, those
 would not get scanned had the array been C-alloced risking active objects to
 get collected?)

Use GC.addRange() to get around this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7095] GC doesn't return or reuse unused memory [D2.056]

2011-12-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7095


deadalnix deadal...@gmail.com changed:

   What|Removed |Added

 CC||deadal...@gmail.com


--- Comment #4 from deadalnix deadal...@gmail.com 2011-12-11 10:27:18 PST ---
(In reply to comment #1)
 D's GC isn't fully precise yet.  In other words, it can't always tell the
 difference between a pointer and a non-pointer.  When you allocate an
 80-megabyte array, the probability that some non-pointer will look like it
 points into the array if interpreted as a pointer is pretty high.  
 
 This is a fundamental limitation of the current garbage collector design,
 rather than a bug.  As a workaround, it's best to use C's malloc for very 
 large
 arrays.

Isn't GC has a flag that says if something may contains pointer or not ?

Why this flag is set when allocation an array of long ?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7095] GC doesn't return or reuse unused memory [D2.056]

2011-12-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7095



--- Comment #5 from David Simcha dsim...@yahoo.com 2011-12-11 10:38:41 PST ---
(In reply to comment #4)
 Isn't GC has a flag that says if something may contains pointer or not ?
 
 Why this flag is set when allocation an array of long ?

It's not.  If a bit pattern in `arr` would point into GC memory if interpreted
as a pointer, then the pattern is ignored.  The GC has some level of precision
in that it knows whether a heap-allocated block contains any pointers or not. 
However, the issue is that pointers **from** somewhere else point **at** arr,
keeping it alive incorrectly.  

There are two sources for false pointers:

1.  The stack, where the GC has no knowledge whatsoever of what's a pointer and
what isn't.  I think this also applies to the static data segment.

2.  Heap allocated data structures that contain both pointer and non-pointer
data, e.g.:

struct Foo {
void* ptr;
size_t num;
}

If you allocate a Foo on the heap, the whole block will be marked as
potentially containing pointers.  The GC won't know what parts of it aren't
pointers.  `num` could have a bit pattern that would be a valid pointer and
will keep some objects alive unnecessarily.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---