I’m using SDL2# (https://github.com/flibitijibibo/SDL2-CS) to interact
with SDL from Mono. In both .NET and Mono, the garbage collector takes
advantage of object finalizers (sort of like a destructor) to clean up
any unmanaged resources that might be still lingering. The GC will call
object finalizers on its own thread, which causes problems when freeing
video related resources such as a texture.
I’ve done a test where I manually dispose of a texture on the main
thread without a hitch. But when I rely on the garbage collector to call
the finalizer which frees the texture, I get a segfault. I’m assuming
this is because the video/event features of SDL are not intended to be
accessed from a separate thread.
Anyone have experience with garbage collectors and memory management of
SDL resources? For now I’m just making sure that I always manually
dispose objects when I’m done with them, but its nice to have the
reassurance of the GC to clean up as well. I haven’t tested it, but I’m
sure Java will have the same problem.
Do not free resources in the finalizer - instead, log a warning that you
forgot to free some resource
Only do #3 in debug mode. Finalizers cost a lot, because they
effectively promote an object from a gen-0 collection to a gen-1
collection. Read here for more details: http://msdn.microsoft.com/en-us/library/ms973837.aspx
If you are working on a game, sooner or later you will want to implement
some form of resource manager to automate resource loading and unloading.
with SDL from Mono. In both .NET and Mono, the garbage collector takes
advantage of object finalizers (sort of like a destructor) to clean up any
unmanaged resources that might be still lingering. The GC will call object
finalizers on its own thread, which causes problems when freeing video
related resources such as a texture.
I’ve done a test where I manually dispose of a texture on the main thread
without a hitch. But when I rely on the garbage collector to call the
finalizer which frees the texture, I get a segfault. I’m assuming this is
because the video/event features of SDL are not intended to be accessed
from a separate thread.
Anyone have experience with garbage collectors and memory management of
SDL resources? For now I’m just making sure that I always manually dispose
objects when I’m done with them, but its nice to have the reassurance of
the GC to clean up as well. I haven’t tested it, but I’m sure Java will
have the same problem.
Python has exactly the same issue (using pysdl2 and del for example).
The go port which was floating around does too.
There isn’t really a good solution as far as I’m aware. The best solution
I’ve seen is to have a ‘dead memory bucket’ and attach native objects hooks
to it when the destructor is invoked. Then in the main thread, periodically
cleanup the dead memory bucket manually.
Ironically, this actually solves a whole bunch of memory jitter bs when you
use go. :p~
Doug.
On Tue, Nov 12, 2013 at 8:15 AM, justin <justin.d.skiles at gmail.com> wrote:
I’m using SDL2# (https://github.com/flibitijibibo/SDL2-CS) to interact
with SDL from Mono. In both .NET and Mono, the garbage collector takes
advantage of object finalizers (sort of like a destructor) to clean up any
unmanaged resources that might be still lingering. The GC will call object
finalizers on its own thread, which causes problems when freeing video
related resources such as a texture.
I’ve done a test where I manually dispose of a texture on the main thread
without a hitch. But when I rely on the garbage collector to call the
finalizer which frees the texture, I get a segfault. I’m assuming this is
because the video/event features of SDL are not intended to be accessed
from a separate thread.
Anyone have experience with garbage collectors and memory management of
SDL resources? For now I’m just making sure that I always manually dispose
objects when I’m done with them, but its nice to have the reassurance of
the GC to clean up as well. I haven’t tested it, but I’m sure Java will
have the same problem.