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
p
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 an
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 on
"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.
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 po
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 that
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
precludin
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 c
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
though,
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
ca
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
re
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
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.
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
core.me
14 matches
Mail list logo
