[Concurrency] Add environment variable for disabling async stack slab allocator. #85259

mikeash · 2025-11-01T00:05:43Z

Add SWIFT_DEBUG_ENABLE_TASK_SLAB_ALLOCATOR, which is on by default. When turned off, async stack allocations call through to malloc/free. This allows memory debugging tools to be used on async stack allocations.

stdlib/public/Concurrency/TaskPrivate.h

compnerd · 2025-11-01T00:09:53Z

stdlib/public/runtime/StackAllocator.h

 /// SlabMetadataPtr specifies a fake metadata pointer to place at the beginning
 /// of slab allocations, so analysis tools can identify them.
-template <size_t SlabCapacity, Metadata *SlabMetadataPtr>
+template <size_t SlabCapacity, Metadata *SlabMetadataPtr, bool (*disableSlabAllocator)()>


Why introduce the type parameter here?

Just to keep StackAllocator reasonably self-contained and unaware of things like debug variables.

But this encodes it right into the type, so it feels like its even more deeply aware of things like debug variables.

stdlib/public/Concurrency/TaskPrivate.h

ktoso · 2025-11-01T01:37:57Z

Very nice, that'll be useful

compnerd

Overall, this seems good. I still thing that this is really over-encoding the environment variable since it encodes it into the type - perhaps we should use the STL approach of _Allocator as a type parameter? That would allow you to hoist the allocator and the knowledge of the environment variable out of the stack allocator itself.

compnerd · 2025-11-01T04:29:21Z

stdlib/public/runtime/StackAllocator.h

+    if (SWIFT_UNLIKELY(EnableSlabAllocator())) {
+      free(ptr);
+      return;
+    }


Suggested change

if (SWIFT_UNLIKELY(EnableSlabAllocator())) {

free(ptr);

return;

}

if (SWIFT_UNLIKELY(EnableSlabAllocator()))

return free(ptr);

rjmccall · 2025-11-01T17:07:41Z

stdlib/public/Concurrency/TaskPrivate.h

+    Enabled,
+    Disabled,
+  };
+  static std::atomic<EnableState> savedState = {EnableState::Uninitialized};


Can this be marked constinit?

We're still on C++17, so unfortunately not.

rjmccall · 2025-11-01T17:10:19Z

stdlib/public/Concurrency/TaskPrivate.h

+    savedState.store(state, std::memory_order_relaxed);
+  }
+
+  return SWIFT_UNLIKELY(state == EnableState::Enabled);


The "unlikely" seems backwards.

Does SWIFT_UNLIKELY actually do anything in a return position?

stdlib/public/runtime/EnvironmentVariables.def

rjmccall · 2025-11-01T17:12:30Z

stdlib/public/runtime/StackAllocator.h

  /// Allocate a memory buffer of \p size.
  void *alloc(size_t size) {
+    if (SWIFT_UNLIKELY(EnableSlabAllocator()))
+      return malloc(size);


You have the condition reversed here and below.

Indeed, I switched it from disable to enable and didn't fix up the uses properly. I rearranged various things and it should be correct now.

rjmccall · 2025-11-01T17:26:55Z

If we expect this to be uncommonly used, it'd be nice to hide it in a path that isn't normally taken. Maybe we can initialize the allocator to ignore the initial slab, and then we only have to check the condition when we'd otherwise be allocating a new slab? There might be a similar unlikely case that we can bury the check during deallocation in, like lastAllocation not being set.

mikeash · 2025-11-03T21:17:02Z

@compnerd The _Allocator approach would involve templating it with a type that has a method that can be called to retrieve the info? Is there a concrete difference from the current approach, other than templating with a type versus a function? I'm happy to make the change, just possibly missing your point.

compnerd · 2025-11-03T21:20:12Z

It is mostly a type vs function thing. The type based approach feels more flexible (and is a general pattern in C++). That should allow you to accomplish the same type of isolation but also opens it up for further expansion in the future without changing the type itself.

mikeash · 2025-11-03T21:24:51Z

Gotcha. I'll make that change, then.

mikeash · 2025-11-03T23:13:31Z

@rjmccall Nice idea about hiding this behind existing conditionals. I pushed changes to make that happen. We now ensure lastAllocation and firstSlab stay initialized to null when the slab allocator is disabled. When allocating, we only check enablement when those are null, which is the case where we'd need to allocate a new slab otherwise. When deallocating, we only check when lastAllocation is null or doesn't match the allocation being freed, which is otherwise a fatal error.

rjmccall

Thanks, a lot happier about this! I think you've got an UNLIKELY backwards, but maybe it doesn't matter for the code-generation.

rjmccall · 2025-11-04T00:09:14Z

stdlib/public/runtime/StackAllocator.h

  Slab *getSlabForAllocation(size_t size) {
    Slab *slab = (lastAllocation ? lastAllocation->slab : firstSlab);
-    if (slab) {
+    if (SWIFT_UNLIKELY(slab)) {


This seems likely.

I blame daylight saving, end of. It actually makes a decent difference in the codegen. Fixing this makes the fast path quite a bit more linear. I was getting a little confused following it around before because it bounced back and forth so much, but didn't quite realize what that meant. Pushed the fix now.

rjmccall

LGTM, thanks!

mikeash · 2025-11-06T21:52:42Z

@swift-ci please test

mikeash · 2025-11-07T20:48:53Z

Now with less build breakage. Needed a little #if action to work in Embedded, and Compatibility56 needed its own copy of StackAllocator.h.

mikeash · 2025-11-07T20:53:49Z

@swift-ci please test

mikeash · 2025-11-07T23:25:47Z

And unittests/runtime/StackAllocator.cpp needed fixing too. Third time's the charm?

mikeash · 2025-11-07T23:25:52Z

@swift-ci please test

… allocator. Add SWIFT_DEBUG_ENABLE_TASK_SLAB_ALLOCATOR, which is on by default. When turned off, async stack allocations call through to malloc/free. This allows memory debugging tools to be used on async stack allocations.

mikeash · 2025-11-08T03:49:12Z

Someday I will remember to update the symbols in the ABI tests.

mikeash · 2025-11-08T03:49:17Z

@swift-ci please test

mikeash requested review from al45tair, compnerd, ktoso and rjmccall as code owners November 1, 2025 00:05

compnerd reviewed Nov 1, 2025

View reviewed changes

mikeash force-pushed the task-allocator-disable-option branch 2 times, most recently from 6bd65ba to 3852a97 Compare November 1, 2025 00:24

ktoso approved these changes Nov 1, 2025

View reviewed changes

compnerd approved these changes Nov 1, 2025

View reviewed changes

rjmccall requested changes Nov 1, 2025

View reviewed changes

mikeash force-pushed the task-allocator-disable-option branch from 3852a97 to 81107a8 Compare November 3, 2025 23:06

rjmccall reviewed Nov 4, 2025

View reviewed changes

rjmccall approved these changes Nov 4, 2025

View reviewed changes

mikeash force-pushed the task-allocator-disable-option branch from 81107a8 to 7e66850 Compare November 4, 2025 02:25

rjmccall approved these changes Nov 4, 2025

View reviewed changes

mikeash force-pushed the task-allocator-disable-option branch from 7e66850 to 07bbbfc Compare November 7, 2025 20:26

mikeash requested a review from a team as a code owner November 7, 2025 20:26

mikeash force-pushed the task-allocator-disable-option branch from 07bbbfc to ecdb965 Compare November 7, 2025 23:25

mikeash force-pushed the task-allocator-disable-option branch from ecdb965 to a62f08e Compare November 8, 2025 03:48

mikeash enabled auto-merge November 8, 2025 03:49

mikeash merged commit f149a8b into swiftlang:main Nov 8, 2025
4 of 5 checks passed

[Concurrency] Add environment variable for disabling async stack slab allocator. #85259

[Concurrency] Add environment variable for disabling async stack slab allocator. #85259

Uh oh!

Conversation

mikeash commented Nov 1, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ktoso commented Nov 1, 2025

Uh oh!

compnerd left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rjmccall commented Nov 1, 2025

Uh oh!

mikeash commented Nov 3, 2025

Uh oh!

compnerd commented Nov 3, 2025

Uh oh!

mikeash commented Nov 3, 2025

Uh oh!

mikeash commented Nov 3, 2025

Uh oh!

rjmccall left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rjmccall left a comment

Choose a reason for hiding this comment

Uh oh!

mikeash commented Nov 6, 2025

Uh oh!

mikeash commented Nov 7, 2025

Uh oh!

mikeash commented Nov 7, 2025

Uh oh!

mikeash commented Nov 7, 2025

Uh oh!

mikeash commented Nov 7, 2025

Uh oh!

mikeash commented Nov 8, 2025

Uh oh!

mikeash commented Nov 8, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants