Custom Allocation


From the Boost Statechart Performance page…

https://www.boost.org/doc/libs/1_70_0/libs/statechart/doc/performance.html#MemoryManagementCustomization


For SMACC, the main strategies regarding allocation should revolve around state and associated object lifetimes.

One interesting idea, is having an option for a state, to be allocated and never deallocated for the life of the state machine, but instead having a clear() function to reset all variables when the state is left. – Would be helpful for relatively small, high performance state machines.

But, it’s also important to separate out the Debug information to a different heap…


I also imagine that we would try to imitate the gaming industry and come up with a toolset of allocators to meet various development needs…

  • Stomp allocators for finding memory leaks…
  • Memory Pool allocators for Persistant vs Temporal objects
  • Small block allocators for events
  • Large block allocators for things like point clouds..
  • etc.

https://stackoverflow.com/questions/826569/compelling-examples-of-custom-c-allocators

https://github.com/electronicarts/EASTL

At 54:09, in the Q&A discussion, it comes out that the EASTL tool is very similar to DTrace and Windows Performance Analyzer

https://docs.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-analyzer

https://www.eclipse.org/tracecompass/

Hacking Babeltrace might me a good option too…

https://lttng.org/viewers/




Monotonic Allocators – Can Thread
Pool Allocator – Can Thread but no Lock Free Implementation
All blocks the same (size of largest allocation)

Multipool Allocator – Solves the same size problem
Sizing is what they do at BMW. Static size is better for repeatable realtime performance

There are slack allocators that do this more dynamically.


An interesting candidate at this point is TLSF (Two Level Segregate Fit) due to it’s real-time capabilities…

http://www.gii.upv.es/tlsf/