[Issue 11021] Huge GC leak leads to crash; GC uses 7x more memory

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=11021



--- Comment #9 from monarchdodra at gmail.com 2013-09-13 12:07:28 PDT ---
(In reply to comment #8)
> 32bits? Allocating large blocks in a loop? 
> Good luck with that... sooner or later they would be pinned by something that
> looks like a pointer to GC.  We are back to false pointers and precise
> collection topic.
> 
> How std.traits affects that is interesting thing, maybe inflates executable
> size. Anyway this is game of chance so any slight change may avoid it or bring
> it back.

2 things I don't understand:

1. New initializes, so the block contains nothing but 0x00's. How could that
contain a false pointers? EDIT: Maybe the size/capacity info is wrongly seen as
pointer?

2. Besides, the GC knows about NO_SCAN, doesn't it? We are explicitly asking
for new ubytes, which is a non-pointer type. Why would the GC scan any of that
at all anywas?

If replace the call with GC.malloc(BIG_SIZE, GC.BlkAttr.NO_SCAN), then my win32
runs forever...

--------

TLDR, I don't see how the false pointer issue in 32 bit environment would
produce this failure.

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