On Friday, 30 November 2012 at 18:46:08 UTC, Dmitry Olshansky
wrote:
I'd just throw in that we have a (almost) precise GC that is
used by at least one large project (the VisualD apparently).
Though there were some problems with it. Anyway I'd expect to
see it in upstream by 2.062 at least.
12/1/2012 2:53 PM, thedeemon пишет:
On Friday, 30 November 2012 at 18:46:08 UTC, Dmitry Olshansky wrote:
I'd just throw in that we have a (almost) precise GC that is used by
at least one large project (the VisualD apparently). Though there were
some problems with it. Anyway I'd expect to see
On Saturday, 1 December 2012 at 12:55:19 UTC, Dmitry Olshansky
wrote:
It should help because:
1) Each allocation happens in a new stack frame thus the
pointer is overwritten each time.
To probably the same stinky value (a false pointer).
2) Precise heap scanning helps this case because it
12/1/2012 10:46 PM, thedeemon пишет:
On Saturday, 1 December 2012 at 12:55:19 UTC, Dmitry Olshansky wrote:
It should help because:
1) Each allocation happens in a new stack frame thus the pointer is
overwritten each time.
To probably the same stinky value (a false pointer).
Pointer is
11/30/2012 12:36 AM, Ali Çehreli пишет:
On 11/29/2012 12:06 PM, Michael wrote:
Because you used uint instead of ubyte, array is bigger, memory
exhausts faster.
Oh, I see.
3. Why it helps?
GC.free(data.ptr);
Initial leak happened because for some reason array allocated in
Because you used uint instead of ubyte, array is bigger, memory
exhausts faster.
Oh, I see.
3. Why it helps?
GC.free(data.ptr);
Initial leak happened because for some reason array allocated
in previous iteration was not collected by GC when allocating
new one, so the new one was allocated
On 11/29/2012 12:06 PM, Michael wrote:
Because you used uint instead of ubyte, array is bigger, memory
exhausts faster.
Oh, I see.
3. Why it helps?
GC.free(data.ptr);
Initial leak happened because for some reason array allocated in
previous iteration was not collected by GC when
A friend of mine reports that the memory usage of the following program
grows continuously when compiled with dmd 2.060 and run on Windows 7 sp1
home premium 64 bit (also on Microsoft Windows [Version 6.1.7600]).
If you are on Windows, could you please say whether you have the same
problem.
11/28/2012 10:51 PM, Ali Çehreli пишет:
A friend of mine reports that the memory usage of the following program
grows continuously when compiled with dmd 2.060 and run on Windows 7 sp1
home premium 64 bit (also on Microsoft Windows [Version 6.1.7600]).
If you are on Windows, could you please
On 11/28/2012 12:57 PM, Dmitry Olshansky wrote:
11/28/2012 10:51 PM, Ali Çehreli пишет:
A friend of mine reports that the memory usage of the following program
grows continuously when compiled with dmd 2.060 and run on Windows 7 sp1
home premium 64 bit (also on Microsoft Windows [Version
On 11/28/2012 11:11 AM, 1100110 wrote:
On 11/28/2012 12:57 PM, Dmitry Olshansky wrote:
11/28/2012 10:51 PM, Ali Çehreli пишет:
A friend of mine reports that the memory usage of the following program
grows continuously when compiled with dmd 2.060 and run on Windows
7 sp1
home premium 64
On 11/28/2012 02:53 PM, Ali Çehreli wrote:
On 11/28/2012 11:11 AM, 1100110 wrote:
On 11/28/2012 12:57 PM, Dmitry Olshansky wrote:
11/28/2012 10:51 PM, Ali Çehreli пишет:
A friend of mine reports that the memory usage of the following
program
grows continuously when compiled with dmd
On Wednesday, 28 November 2012 at 22:02:35 UTC, Michael wrote:
Only 3 iterations before out of memory exception?
Because you used uint instead of ubyte, array is bigger, memory
exhausts faster.
3. Why it helps?
GC.free(data.ptr);
Initial leak happened because for some reason array
13 matches
Mail list logo
