3 ms·

> guarantee type stable allocations: once an address has been used to fulfill a request for a certain allocation class, it will only be used for that class. Sli

> guarantee type stable allocations: once an address has been used to fulfill a request for a certain allocation class, it will only be used for that class. Slitter doesn’t overlay intrusive lists on top of freed allocations, so the data always reflects what the application last stored there. This means that double-frees and use-after-frees only affect the faulty allocation class. An application could even rely on read-after-free being benign to simplify non-blocking algorithms. This is really fascinating. Does anyone know how much the typical cost of such types of guarded allocations are? is it in the single/double digit percentages?

deleted 5y ago
[deleted]
wahern 5y ago
Intrusive vs. not-intrusive isn't nearly sufficient to make that comparison. For example, in phkmalloc the switch to a separate index generally improved performance relative to the allocator being replaced: http://phk.freebsd.dk/pubs/malloc.pdf http://phk.freebsd.dk/pubs/malloc.pdf However, from that paper it seems that the previous allocator made some particularly bad choices that resulted in unnecessarily poor cache locality. OpenBSD's allocator uses a separate index, as well as many more mitigations (many more than Slitter), and unfortunately OpenBSD's allocator ends up being substantially, even notoriously slower than most other allocators. But, again, this has little to do with using a separate index, except that using a separate index opens the door to many other potential mitigations. And where ever there's a choice between performance or mitigation, OpenBSD usually takes the latter (though sometimes they walk that back as usage and efficacy become more clear).
- lep 5y ago
  I can only advise everybody to run your C program under OpenBSD. I maintain a tool which is probably run against million lines of code and which i tested under FreeBSD, Windows and Linux where it worked. But recently i ran it the first time under OpenBSD and it SEGFAULTed almost immediatly. Of course it was an error on my side. It was a beautiful experience.

deleted 5y ago

[deleted]

wahern 5y ago

Intrusive vs. not-intrusive isn't nearly sufficient to make that comparison. For example, in phkmalloc the switch to a separate index generally improved performance relative to the allocator being replaced: http://phk.freebsd.dk/pubs/malloc.pdf http://phk.freebsd.dk/pubs/malloc.pdf However, from that paper it seems that the previous allocator made some particularly bad choices that resulted in unnecessarily poor cache locality. OpenBSD's allocator uses a separate index, as well as many more mitigations (many more than Slitter), and unfortunately OpenBSD's allocator ends up being substantially, even notoriously slower than most other allocators. But, again, this has little to do with using a separate index, except that using a separate index opens the door to many other potential mitigations. And where ever there's a choice between performance or mitigation, OpenBSD usually takes the latter (though sometimes they walk that back as usage and efficacy become more clear).

lep 5y ago
I can only advise everybody to run your C program under OpenBSD. I maintain a tool which is probably run against million lines of code and which i tested under FreeBSD, Windows and Linux where it worked. But recently i ran it the first time under OpenBSD and it SEGFAULTed almost immediatly. Of course it was an error on my side. It was a beautiful experience.