The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
Custom memory management
Camilo Bravo Valdés
Guest

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.
AntTheAlchemist


Joined: 13 Feb 2015
Posts: 60
Location: UK
+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.
Custom memory management
Jared Maddox
Guest

Quote:
Date: Thu, 2 Jul 2015 08:44:10 -0700
From: Camilo Bravo Vald?s
To:
Subject: [SDL] Custom memory management
Message-ID:

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.


Quote:
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.


Quote:
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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Custom memory management
Sik


Joined: 26 Nov 2011
Posts: 905
2015-07-12 2:47 GMT-03:00, Jared Maddox:
Quote:
Quote:
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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Custom memory management
Camilo Bravo Valdés
Guest

Quote:
 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 <insert hexadecimal number here> 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.