-
Notifications
You must be signed in to change notification settings - Fork 763
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump stackguard depths values by 10% #16754
base: main
Are you sure you want to change the base?
Conversation
❗ Release notes requiredCaution No release notes found for the changed paths (see table below). Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format. The following format is recommended for this repository:
If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request. You can open this PR in browser to add release notes: open in github.dev
|
Please test it carefully on macOS, where the stack size is the smallest and where the most of stackoverlow reports were coming from before this guard was added. There were many reports coming from macOS users. Maybe we could use different sizes depending on the used OS somehow? |
Yes, I have another branch that sets the limit according to the platform. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I would be extremely careful with it, there's no way really to properly test it except of some sort of fuzzing (which we are lacking now).
#endif | ||
|
||
static member GetDepthOption(name: string) = | ||
GetEnvInteger ("FSHARP_" + name + "StackGuardDepth") StackGuard.DefaultDepth | ||
|
||
static member GetOsDependentDepth(mac: int, unix: int, win: int, other: int) : int = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be inline, also should be taking an environment variable as parameter and taking value from env inside.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, yeah, looks nice. Just the inlining is an issue:
C:\Users\schae\src\fsharp\src\Compiler\Facilities\DiagnosticsLogger.fs(882,9): warning FS1116: A value marked as 'inline' has an unexpected value [C:\Users\schae\src\fsharp\src\Compiler\FSharp.Compiler.Service.fsproj::TargetFramework=netstandard2.0]
C:\Users\schae\src\fsharp\src\Compiler\Facilities\DiagnosticsLogger.fs(882,9): error FS1114: The value 'FSharp.Compiler.DiagnosticsLogger.StackGuard.GetOsDependentDepth' was marked inline but was not bound in the optimization environment [C:\Users\schae\src\fsharp\src\Compiler\FSharp.Compiler.Service.fsproj::TargetFramework=netstandard2.0]
C:\Users\schae\src\fsharp\src\Compiler\Facilities\DiagnosticsLogger.fs(888,26): error FS1113: The value 'GetOsDependentDepth' was marked inline but its implementation makes use of an internal or private function which is not sufficiently accessible [C:\Users\schae\src\fsharp\src\Compiler\FSharp.Compiler.Service.fsproj::TargetFramework=netstandard2.0]
C:\Users\schae\src\fsharp\src\Compiler\Facilities\DiagnosticsLogger.fs(882,9): error FS1118: Failed to inline the value 'GetOsDependentDepth' marked 'inline', perhaps because a recursive value was marked 'inline' [C:\Users\schae\src\fsharp\src\Compiler\FSharp.Compiler.Service.fsproj::TargetFramework=netstandard2.0]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, that is awkward...It's fine then, JIT will be able to inline it likely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll look into inlining issue though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer not to have code that compiles on windows but not the mac. So probably keep the limits the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is all the way around, on Mac the limit is lower -> we will spawn another thread earlier. So it will work, but will have different frames limit on different OSs
Ironically, I ran benchmarks on this branch (on macOS), and immediately got SO :D To be fair, I've gotten the same on the |
Yeah, main and this branch should be the same regarding macOs, as there's no bump for macOS in this branch. |
Description
Just an experiment to see if this is still safe for the CI.
Currently used stackguard depths:
Every stackguard depth x 1.1:
Checklist
Test cases added
Performance benchmarks added in case of performance changes
Release notes entry updated: