Not sure if this topic has been dealt with before, but for some reason the
search functionality of the archives isn’t working, so I cannot be sure.
Currently, there’s no way to intercept SDL’s requests for memory management
unless SDL_malloc and the likes are modified. Totally cool and (sort of)
painless to do this, but I’d prefer to simply “inject” the functions to be
used instead, and let SDL use these every time it needs to (re)allocate or
free memory.
Rewriting SDL_malloc, SDL_realloc, SDL_calloc, and SDL_free to use
custom memory management routines is a no-brainer, really, but I’ve found
that I’d also have to modify each call inside the library, because I’ve
been tagging each allocation with a “label” to help identify the usage
pattern and hence decide which approach to use (e.g. I need 120 KB for a
surface, ok, not a big deal since I’ll be loading it only once, but now I
need 100 bytes for a log message, let me use a pool for that instead).
Currently, SDL doesn’t “classify” allocations into categories this way.
Is there any plan to change this? At Steam Dev Days someone asked about it
(I think that was the question, the person asking didn’t use a microphone)
and Ryan Gordon said it’d be nice to incorporate such functionality into
the library, but I began using SDL only a couple of weeks ago, so I’m don’t
know what the current roadmap is.
+1 for this idea.
I’m overriding the new and delete operators in C++ to implement my own memory management and even garbage collection, which works great; I don’t ever need to deal with a failed memory allocation, since the manager does it for me.
I remember the question being raised in the Steam Q&A session being about SDL having its own garbage collection. Bad idea. Garbage collection in C/C++ in my experience works better per-application because only the application knows best what type of memory to free and where to free it and in what priority to “collect the garbage”. For instance: I unload non-essential animation sprite objects if there is no other option - something a generic garbage collection cannot do.
LodePNG has memory allocation functions which you can override. SDL2 can easily do the same please.
Message-ID:
<CADbmW4OoqNV-TBryV5wva4q97T84kUh3-otZ3S4+CJwCcJG8qQ at mail.gmail.com>
Content-Type: text/plain; charset=“utf-8”
Not sure if this topic has been dealt with before, but for some reason the
search functionality of the archives isn’t working, so I cannot be sure.
Currently, there’s no way to intercept SDL’s requests for memory management
unless SDL_malloc and the likes are modified. Totally cool and (sort of)
painless to do this, but I’d prefer to simply “inject” the functions to be
used instead, and let SDL use these every time it needs to (re)allocate or
free memory.
Sensible idea. Why don’t you write a proof-of-concept? Remember,
you’ll likely need to set the function hooks before initializing the
library, not after.
Rewriting SDL_malloc, SDL_realloc, SDL_calloc, and SDL_free to use
custom memory management routines is a no-brainer, really, but I’ve found
that I’d also have to modify each call inside the library, because I’ve
been tagging each allocation with a “label” to help identify the usage
If your modifications involve adding these tags to the function
signature, then don’t make that modification. Instead, define an
additional function that you call BEFORE the allocator calls, and
clear in the actual allocator functions themselves.
pattern and hence decide which approach to use (e.g. I need 120 KB for a
surface, ok, not a big deal since I’ll be loading it only once, but now I
need 100 bytes for a log message, let me use a pool for that instead).
Currently, SDL doesn’t “classify” allocations into categories this way.
And I assume never will, since this is not a "generic allocator"
trait. SDL’s allocators are direct wrappers of the platform’s standard
C library routines in pleanty of cases, and thus need to maintain the
same function signature (unless the preprocessor macros got replaced).
Non-generic allocations should realistically be done either behind the
scenes, or in a seperate library.> Date: Thu, 2 Jul 2015 08:44:10 -0700
From: Camilo Bravo Vald?s
To: sdl at lists.libsdl.org
Subject: [SDL] Custom memory management
2015-07-12 2:47 GMT-03:00, Jared Maddox :
pattern and hence decide which approach to use (e.g. I need 120 KB for a
surface, ok, not a big deal since I’ll be loading it only once, but now I
need 100 bytes for a log message, let me use a pool for that instead).
Currently, SDL doesn’t “classify” allocations into categories this way.
And I assume never will, since this is not a "generic allocator"
trait. SDL’s allocators are direct wrappers of the platform’s standard
C library routines in pleanty of cases, and thus need to maintain the
same function signature (unless the preprocessor macros got replaced).
Non-generic allocations should realistically be done either behind the
scenes, or in a seperate library.
For the record, I think that splitting allocations like that is how
Windows’ allocator works (if the allocation is small enough it gets
stored into a dedicated pool, otherwise it gets a proper new block in
the heap). Note that such a thing can be done behind the scenes since
it only relies on the size of the block to figure it out, nothing
else.
Sensible idea. Why don’t you write a proof-of-concept?
I actually went and modified these functions to fit my interface and then
tried building the library. This way I could locate every call (lots of
them, by the way; this wasn’t an enjoyable task) and wrote down the file,
function name and line number from where the calls were issued (again, I
didn’t enjoy this).
What caught my attention was the fact that (except for logging) SDL doesn’t
really do anything particularly silly when asking for memory to the system,
i.e. the library naturally fits into the “load any stuff you need before
entering the computationally intensive part of your application and then
don’t do anything crazy with memory” approach. At least for a PC (or Mac,
whatever), there shouldn’t be any issue at all if the application follows a
reasonable “flow” — from what I’ve read, the general-purpose allocators
in these systems do a pretty good job most of the cases. As for mobile
devices, the story could be different; I’m not really familiar with such
environments.
My point is: unless one’s a control freak and would like to know where did
byte came from, I guess it’b be fine to
let SDL do what it’s been doing all along and, instead, don’t be silly and
load a texture every frame.