2 ms·
But you could, for instance, allocate arenas at the beginning of execution and then do virtual allocations inside this for the rest of execution, no?
by skohan 7y ago
But you could, for instance, allocate arenas at the beginning of execution and then do virtual allocations inside this for the rest of execution, no?
- stjohnswarts 7y agoI'm not sure what arenas are but you can certainly use pre allocated memory pools to bound a custom malloc/free in both time and space.
- eru 7y agoYes, you can do that. It's just not native malloc / free anymore. Of course, you need to be careful about your manual approach. Both to avoid mistakes, but also to actually achieve the performance goals you have.
- skohan 7y agoTo the original point, at least C/C++ allow you to do this type of memory management, even if it's not the 'default' strategy. It's not so clear how you would achieve something like this in Go or Java.
- eru 7y agoAgreed. I wasn't contesting that point at all, just elaborating. Most of the time for most people, the risk of arbitrarily long pauses from malloc/free is only a theoretical concern. Pauses from your typical GC are a practical concern more often. Reference counting lies in the middle. If you drop the last reference to a big part of your object graph, it can take an arbitrarily long time to clean up as well. You can bound it by either being careful how you construct (and deconstruct) your object graph at application level; or you can go for a more sophisticated real-time variant of reference counting. Google has lots of hits for 'real time reference counting'.