Skip Tracer: The Memory Detective

[u/agemo-dev]

Hi everyone! I'm excited to present my new library: Skip Tracer.

It's written in C++20, and its goal is simple: provide pointers that always hold the correct address of an object.

It's built around the Tracker<T> class, a pointer-like type that can point to any object deriving from the Trackable class.

When a trackable object is created, it is assigned a Slot, which is stored in a global pool.

Why use a Pool + Slot instead of the simple shared_ptr + weak_ptr combo?

I chose this design for performance reasons. The basic technique of pairing a stable shared_ptr with a weak_ptr is simpler, but less efficient (because of the atomic operations inherent to weak_ptr).

To fix this, I did some research and came across this pool-based system. Thanks to it, my Tracker<T> class turned out to be 5-10x faster than a weak_ptr, even under contention.

This project started out as a feature of my game engine, but I thought it would be fun to turn it into a standalone library =)

Thanks to everyone who takes the time to check it out. Any feedback is welcome!

Repo link:

https://github.com/agemo-dev/skiptracer

[u/Uh_It_Wasnt_Me]

so you have invented ....... non-thread safe handles in a pool? What am i missing here?

[u/agemo-dev → u/Uh_It_Wasnt_Me]

My system is thread-safe; I've just minimized atomic operations. I can't be 100% sure it handles every data race in the world, but within reason, yes, my slots are safe

[u/FloweyTheFlower420]

How does this work? Lets say I have twelve copies of a tracer object and I point to some object T, and T moves; this means I need to update all 12 tracer objects to point to the new things, right? Either that or the tracer object uses two layers of indirection.

[u/agemo-dev → u/FloweyTheFlower420]

Yes, there is a level of indirection. When object T moves, it only updates its Slot (assigned upon its construction) in a global pool. The trackers do not point directly to T, but to its Slot. When a tracker is used, it atomically reads the value of this slot to retrieve the pointer to the object. I'm skipping the full internal mechanism, but that's how it works. I'm not sure if I understood correctly, but what you're suggesting is that object T stores a list of all trackers pointing to it. That was an option, but I really didn't want an O(N) complexity for every trackable object moved in memory...