[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 #10 from Dmitry Olshansky <dmitry.olsh at gmail.com> 2013-09-13 13:22:18 PDT ---
(In reply to comment #9)
> (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

False pointers that HAPPEN TO POINT INTO THAT BLOCK. I can't imagine we are
having this conversation again. The larger the block the better target it
makes.

> 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?
> 

Yes it SHOULDN'T scan THAT BLOCK.

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

Or change something else and it might not... ? This is an erratic issue.

> --------
> 
> 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: -------