servo: Allow configuring style stack size by jschwe · Pull Request #269 · servo/stylo

jschwe · 2025-11-15T12:25:39Z

When running Servo with ASAN we hit the stack limit. We can use compile-time parsing of environment variables, to allow the embedder to configure the style thread stack size.

Fixes #223

mrobinson · 2025-11-17T23:28:14Z

style/parallel.rs

+pub const STYLE_THREAD_STACK_SIZE_KB: usize = const {
+    let default_stack_size = 512;
+    if let Some(user_def_size) = option_env!("SERVO_STYLE_THREAD_STACK_SIZE_KB") {
+        if let Ok(user_def_size) = usize::from_str_radix(user_def_size, 10) {
+            user_def_size
+        } else {
+            panic!("SERVO_STYLE_THREAD_STACK_SIZE_KB must be a valid integer")
+        }
+    } else {
+        default_stack_size
+    }
+};


Would it be possible to make this a bit simpler and just increase the stack size when ASAN is enabled?

Given servo/servo#40814 I would also like to do this for debug builds, if possible.

I would prefer keeping it configurable too, since it allows embedders to adjust the stack size based on their needs.
The code is quite simple, just very verbose since we can't use any traits in const contexts, like and_then() or unwrap_or().

@mrobinson Coming back to this, could we revive the discussion here on how to continue?

Given servo/servo#40814 I would also like to do this for debug builds, if possible.

We have already increased the size here just for Servo due to our debug builds. I guess we could increase it again. If possible, it would be nice to have the build just work, no matter the build configuration, without having to set a magic environment variable. Also, what are the implications of exposing this in production builds?

Yet...why do we need a larger stack size than Gecko?

Also, what are the implications of exposing this in production builds?

The environment variable is read at compile-time, so I don't see any issue there.

We have already increased the size here just for Servo due to our debug builds. I guess we could increase it again. If possible, it would be nice to have the build just work, no matter the build configuration, without having to set a magic environment variable.

As I understand, the whole point of this setting is to reduce the amount of memory the stylo threads use (since AFAIK the default is higher, I don't remember exactly but either 2 or 8 MB?). Increasing works, but it since release / production builds will require less memory due to optimizing, it would also be wasteful to just choose the highest option.

Yet...why do we need a larger stack size than Gecko?

I wonder if they perhaps always optimize stylo to a certain degree? (pure speculation)

I would also like to do this for debug builds, if possible.

The difficult thing here is that we can't detect that. We can only check debug-assertions, but we also enable those in release mode in servo so it's not optimal.

But I guess I could live with a cfg(any(debug_assertions, asan)), although I'm not a huge fan, if thats preferred.

The difficult thing here is that we can't detect that. We can only check debug-assertions, but we also enable those in release mode in servo so it's not optimal.

Thinking about it again, we need to ensure that we run servo CI with the smaller stack size, to prevent sudden crashes in production. And since we do want to enable debug_assertions in servos CI, those two goals kind of exclude themselves. So we are back to the embedder build system somehow needing to pass the information to stylo, which could either be a cfg, which would be a global rustflag, a feature flag "debug", or an environment variable like the current one.

Apparently, Gecko's default debug build does include some Rust optimizations. Maybe we could do that same.

Apparently, Gecko's default debug build does include some Rust optimizations. Maybe we could do that same.

I'm not opposed to that. IMHO it might make sense to optimize all non-workspace dependencies in servo with 1 or perhaps even 2. It would slow down clean debug builds, improve the performance of debug builds, and perhaps slightly regress the ability to debug issues in non-workspace dependencies with gdb. Seems like a trade-off we could make if we document it properly in the book.

Anyway, we would probably still need to increase the stack size for asan, although a global cfg option for that would be fine, since we anyway need to set rustflags for asan.

mrobinson · 2026-01-20T10:00:49Z

style/parallel.rs

+    let default_stack_size = 512;
+    if let Some(user_def_size) = option_env!("SERVO_STYLE_THREAD_STACK_SIZE_KB") {
+        if let Ok(user_def_size) = usize::from_str_radix(user_def_size, 10) {
+            user_def_size
+        } else {
+            panic!("SERVO_STYLE_THREAD_STACK_SIZE_KB must be a valid integer")
+        }
+    } else {
+        default_stack_size
+    }


Can map be used here?

I'm pretty sure I tried that, and its not available in const contexts sadly.
Edit: docs.rs confirms map on option is still unstable in const contexts.

When running Servo with ASAN we hit the stack limit. We can use compile-time parsing of environment variables, to allow the embedder to configure the style thread stack size.

jschwe · 2026-01-22T11:15:08Z

FYI, I can't merge to this repo, so someone else would need to click the merge button if everything is alright otherwise.

Stylo servo/stylo#269 recently added the option to configure the stack size of the style threads. We increase the stack size for asan and debug builds. Signed-off-by: Jonathan Schwender <[email protected]>

When running Servo with ASAN we hit the stack limit. We can use compile-time parsing of environment variables, to allow the embedder to configure the style thread stack size. Fixes #223

Loirooriol

Instead of an env, wouldn't it be better to use style_config::get_i32() to get a pref that can be set from Servo? Like

stylo/style/global_style_data.rs

Line 159 in 3b46f3e

style_config::get_i32("layout.threads")

…-style-system-reviewers,dshin This imports servo/stylo#269 Differential Revision: https://phabricator.services.mozilla.com/D286391

…-style-system-reviewers,dshin This imports #269 Differential Revision: https://phabricator.services.mozilla.com/D286391

jschwe mentioned this pull request Nov 15, 2025

ASAN: heap-use-after-free in canvas_traits::webgl::WebGLMsgSender::send: on jingdong.com servo/servo#40655

Closed

mrobinson reviewed Nov 17, 2025

View reviewed changes

jdm mentioned this pull request Nov 22, 2025

"illegal hardware instruction" on MacOS servo/servo#40814

Closed

Loirooriol force-pushed the main branch from a47ab67 to b5fc407 Compare January 6, 2026 19:48

Loirooriol force-pushed the main branch from b5fc407 to 71737ad Compare January 15, 2026 10:48

mrobinson approved these changes Jan 20, 2026

View reviewed changes

servo: Allow configuring style stack size

9f84f72

When running Servo with ASAN we hit the stack limit. We can use compile-time parsing of environment variables, to allow the embedder to configure the style thread stack size.

jschwe force-pushed the style_thread_stack_size_configure branch from 7c96acc to 9f84f72 Compare January 20, 2026 10:13

mrobinson added this pull request to the merge queue Jan 22, 2026

Merged via the queue into servo:main with commit 9c1d70b Jan 22, 2026
5 checks passed

jschwe deleted the style_thread_stack_size_configure branch January 22, 2026 14:07

Loirooriol reviewed Feb 6, 2026

View reviewed changes

mrobinson mentioned this pull request Feb 20, 2026

AutoRealm is bad servo/mozjs#709

Open

Conversation

jschwe commented Nov 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

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!

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!

jschwe Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jschwe commented Jan 22, 2026

Uh oh!

Uh oh!

Loirooriol left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jschwe commented Nov 15, 2025 •

edited

Loading

jschwe Jan 20, 2026 •

edited

Loading

Loirooriol left a comment •

edited

Loading