-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
PCRE2: allocate jit stack/match data once per thread #15955
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
PCRE2: allocate jit stack/match data once per thread #15955
Conversation
Grmbl. macOS CI is acting up again 😡 |
macOS seems still broken. Any idea what's happening? Can someone with a mac check if this reproduces locally (and optionally investigate)? |
Sigh. I'll have to start a tmate-action to see what's happening 😞 |
It seems to avoid a segfault on Darwin on CI, which may just be related to the old LLVM 11 version that we still use in shell.nix that's only use on the macOS CI woprkflow.
Hum, it still segfaults on x86_64-darwin but not on aarch64-darwin 🤨 |
This reverts commit b85d9be.
Trying to set the struct's `@key` in the `#initialize` methods leads to a segfault when the struct will be set as a global (for example a class variable).
Progress on macOS: I tried everything I could think of, and it eventually worked correctly on x86_64-darwin, but the process will segfault whenever we unwind the stack (e.g. we raise an exception). On the other hand, |
Allocates the PCRE2 jit stack scratch space and match data once per thread, instead of once per thread and per regular expression.
Uses the new internal
Thread::Local(T)
type to store the allocations, along with a destructor to make sure that the allocations will be freed when a thread terminates — no strong dependency, the library won't be linked if PCRE2 isn't used.Bonuses:
Removes the last usage of
Crystal::ThreadLocalValue
outside ofIO::Evented
(used by libevent and wasi).Creating and accessing the jit stack and match data no longer needs to go through a Mutex (contention) or a Hash (complexity), we just go through a libc fun call.
Regular expressions shall thus be faster, at the expense of some memory, maybe (large allocated match data).
Follow up to #15616.
Obsoletes #15395 (where there are more details)