PCRE2: optimize memory allocations

[ysbaddaden]

We noticed in #15088 that we don't need Crystal::ThreadLocalValue in the Regex PCRE2 engine.

We can reuse the JIT stack but also the match data for every Regex (no need for a specific match data per Regex). We can allocate one and make sure it's not used by other threads... hence the thread locals: no more spinlock (thread contention) nor hash.

It's simpler and faster. Here's the benchmark from #13144 for example:

$ crystal run --release bench/regex.cr
starts_with?  29.46M ( 33.94ns) (± 0.27%)
    matches?  40.34M ( 24.79ns) (± 0.74%)
$ bin/crystal run --release bench/regex.cr
starts_with?  30.70M ( 32.58ns) (± 0.26%)
    matches?  46.28M ( 21.61ns) (± 0.72%)

Enabling MT also no longer has any impact on performance:

$ crystal run --release -Dpreview_mt bench/regex.cr
starts_with?  26.50M ( 37.73ns) (± 0.09%)
    matches?  41.75M ( 23.95ns) (± 0.56%)
$ bin/crystal run --release -Dpreview_mt bench/regex.cr
starts_with?  30.61M ( 32.67ns) (± 0.36%)
    matches?  48.45M ( 20.64ns) (± 1.51%)

The drawback is that we must allocate each matchdata with a maximum number of ovectors (65535). That might increase memory usage, though I failed to notice it in practice. Maybe not allocating memory for every regular expression is helping?

Note: this PR will be separated into a couple PRs to introduce Crystal::System::ThreadLocal(T). The point of this new type is for this patch, so I want approval on the overall approach before the split.

I could have used @[ThreadLocal] but some targets don't support it (namely: Android, MinGW and OpenBSD) and we can't register destructors either (on thread shutdown). But using pthread_key_create or FlsAlloc we can 😍

[ysbaddaden]

Damn, that was promising, and it's working well on Linux, but both Darwin and Windows completely broke 😭

Windows could be explained by using FlsAlloc instead of TlsAlloc, but Darwin?

[ysbaddaden]

WTH: I can't reproduce the errors in my Windows VM (MSVC) 😕

[ysbaddaden]

I can reproduce when running the compiler specs. Looking at the memory graph, the committed memory keeps growing rapidly, and it starts failing exactly when reaching 32GB (the VM has 16GB of RAM). That can't be a coincidence.

When running the compiler specs from master, the committed memory is rather stable or grows slowly (around 3.5GB). Let's note that a linker command still fails, but I get a bunch of weird spec errors in the VM.

Maybe FlsAlloc ain't exactly compatible with our fiber-context switch (argh)?