Remove ChunkAllocator #491
Conversation
mjp41
force-pushed
the
predecayrange
branch
4 times, most recently
from
2dde429 to
0f38f82
Compare
src/mem/corealloc.h
Outdated
| @@ -282,7 +281,7 @@ namespace snmalloc | |||
| bumpptr = slab_end; | |||
| } | |||
|
|
|||
| ChunkRecord* clear_slab(Metaslab* meta, smallsizeclass_t sizeclass) | |||
| Metaslab* clear_slab(Metaslab* meta, smallsizeclass_t sizeclass) | |||
There was a problem hiding this comment.
The return here was always just a type pun and can probably be done away with now.
There was a problem hiding this comment.
Good point. I had removed the use-site, but not the return.
| } | ||
| return tid; | ||
| } | ||
|
|
There was a problem hiding this comment.
Generally approve of the idea, but should this actually be in the PAL so we can actually get the platform notion of a thread ID (when it's sufficiently inexpensive to do so)?
There was a problem hiding this comment.
Mostly, I just needed some logging that I could uninterleave ;-) Happy for something better to be done. I can drop this commit from the PR, and someone can do something better, or I can leave this, and then someone can improve if they have bandwidth?
My preference is for the later, but what do you think.
There was a problem hiding this comment.
This is a strict improvement, so no reason to drop it. Was mostly asking in case there was reason not to do the PAL thing.
There was a problem hiding this comment.
I was trying to trace a bug in DecayRange which only exhibited with concurrency, and this was the quickest thing I could do to get a trace I could understand. I think we can engineer something better.
There was a problem hiding this comment.
I think we can engineer something better.
But not tonight ;-)
| @@ -24,6 +24,8 @@ namespace snmalloc | |||
|
|
|||
| static constexpr bool Aligned = pal_supports<AlignedAllocation, PAL>; | |||
|
|
|||
| static constexpr bool ConcurrencySafe = true; | |||
There was a problem hiding this comment.
While true at the moment, do we want to promise that all PALs have concurrency-safe (de)alloc routines?
There was a problem hiding this comment.
Good question. I could say false instead? Or we could add a feature flag to each Pal that says if it is true?
There was a problem hiding this comment.
The Pals have always been assumed to be concurrency safe so far.
Automatically prepend messages with a thread id. Makes debugging easier.
Now we have an allocation free formatting routine, remove std::cout from tracing.
Ranges can be safe to call from multiple threads. This adds a constexpr field to signify if that is the case.
This is the first commits for adding the DecayRange. It involves