If I pool all unused objects such that no object needs to be
GC'ed, does it still perform scanning? What are other good ways
to avoid its overhead? As you might tell, I know rather little
how D's garbage collection works. I'm working on a game engine
and trying to be as resource efficient as
Jonathan wrote in message news:hsdxglmqtcnhskwzr...@forum.dlang.org...
If I pool all unused objects such that no object needs to be GC'ed, does
it still perform scanning? What are other good ways to avoid its overhead?
As you might tell, I know rather little how D's garbage collection works.
On Monday, 6 October 2014 at 16:23:41 UTC, Jonathan wrote:
If I pool all unused objects such that no object needs to be
GC'ed, does it still perform scanning? What are other good ways
to avoid its overhead? As you might tell, I know rather little
how D's garbage collection works. I'm working
Kiith-Sa, thanks for the info! I started to check out your entity
project and love how your incorporating threads and syncing
new/old state. You did state that your cleaning up things, but my
initial reaction is that entitymanager is performing too many
roles. I'd remove the heavy game state
On Monday, 6 October 2014 at 17:46:34 UTC, Jonathan wrote:
Kiith-Sa, thanks for the info! I started to check out your
entity project and love how your incorporating threads and
syncing new/old state. You did state that your cleaning up
things, but my initial reaction is that entitymanager is
On Sunday, 6 July 2014 at 04:58:42 UTC, Brian Schott wrote:
So something like this would work?
void* GCAwareRealloc(void* ptr, size_t size)
{
import core.thread;
void* r;
thread_enterCriticalRegion();
scope (exit) thread_exitCriticalRegion();
r = realloc(ptr, size);
// Assuming
On Friday, 4 July 2014 at 17:05:32 UTC, David Nadlinger wrote:
On Friday, 4 July 2014 at 14:47:12 UTC, Chris Cain wrote:
Is there a way to lock the GC currently?
There are critical regions in core.thread. While in such a
region, your thread will never be suspended, effectively also
On Thursday, 3 July 2014 at 21:53:25 UTC, Brian Schott wrote:
I think that the only sane way to solve this is to define in
the specs for core.memory that GC.addRange will only ever store
one entry per pointer, and that the length will be the value of
sz from the most recent call to addRange.
If you reallocate doubling the size, it's likely such reallocs
always move, so they should be equivalent to malloc+free, so your
code can be
mem2 = alloc(sz*2);
mem2[] = mem1[];
addRange(mem2);
removeRange(mem1);
free(mem1);
if not, you need to lock the GC so that it won't interfere during
On Friday, 4 July 2014 at 10:36:03 UTC, safety0ff wrote:
I just thought a little more about this and you will always
have a race.
Consider this code:
auto a = malloc(aSize);
GC.addRange(a, aSize);
auto b = realloc(a, aSize * 2);
If realloc moves the data (a != b) and the GC runs before you
On Friday, 4 July 2014 at 14:47:12 UTC, Chris Cain wrote:
Is there a way to lock the GC currently?
There are critical regions in core.thread. While in such a
region, your thread will never be suspended, effectively also
precluding the GC from running. They are a rather dangerous tool
On Friday, 4 July 2014 at 14:47:12 UTC, Chris Cain wrote:
If GC.enable and GC.disable truly disallowed GC running (or
alternative `GC.hard_disable`/`GC.hard_enable` existed that
guaranteed such) then you could use that to make sure that the
GC didn't collect in the middle of a pair of those
Experience has shown that using allocators can drastically
improve the execution time of D programs. It has also shown that
the biggest issue with allocators is that unless you are very
careful, the GC will start freeing your live memory.
I think that we need to define the behavior of
On Thursday, 3 July 2014 at 21:53:25 UTC, Brian Schott wrote:
I think that the only sane way to solve this is to define in
the specs for core.memory that GC.addRange will only ever store
one entry per pointer, and that the length will be the value of
sz from the most recent call to addRange.
Hello everyone,
I was writing some unit tests and I also wanted to test that in certain
cases object references are properly removed everywhere so that GC can
collect them in order to make sure there is no memory leak. While trying
to achieve this I learned that objects are not always
On 11/06/2012 03:27 AM, luka8088 wrote:
I was writing some unit tests and I also wanted to test that in certain
cases object references are properly removed everywhere so that GC can
collect them in order to make sure there is no memory leak. While trying
to achieve this I learned that
On Tuesday, 6 November 2012 at 11:27:25 UTC, luka8088 wrote:
Hello everyone,
I was writing some unit tests and I also wanted to test that in
certain cases object references are properly removed everywhere
so that GC can collect them in order to make sure there is no
memory leak. While trying
On 6.11.2012 18:00, Ali Çehreli wrote:
On 11/06/2012 03:27 AM, luka8088 wrote:
I was writing some unit tests and I also wanted to test that in certain
cases object references are properly removed everywhere so that GC can
collect them in order to make sure there is no memory leak. While
On 6.11.2012 18:02, thedeemon wrote:
On Tuesday, 6 November 2012 at 11:27:25 UTC, luka8088 wrote:
Hello everyone,
I was writing some unit tests and I also wanted to test that in
certain cases object references are properly removed everywhere so
that GC can collect them in order to make sure
On 6.11.2012 21:59, Ali Çehreli wrote:
On 11/06/2012 12:00 PM, luka8088 wrote:
Yes, but it seems that we can in general say that the following code
will never fail... or am I wrong ?
import core.memory;
class a {
static int totalRefCount = 0;
this () { totalRefCount++; }
~this
20 matches
Mail list logo
