PikachuEXE

So to test it I just change `fork_worker` to `mold_worker`? Other callbacks like `on_refork` are all the same? (No change needed

Running following on a small app (too lazy to have decent memory monitoring) for a week ```ruby mold_worker(400, 800, 1600, 3200) on_mold_promotion do # Run GC before forking 3.times {GC.start}...

> `mold_worker` is capable of reforking at multiple intervals; by default it will trigger one mold promotion and a phased refork at 1000 requests, but you can pass 1..n intervals...

For every `worker_check_interval` (default 10s) there is a ping And every worker will be pinged (in sequence I guess If `requests_count` > `next_request_interval` (when present) e.g. for `400, 800, 1600`...

> after the first refork every worker starts at 400 requests and only has to do 400 more to trigger the next mold and refork I think this is not...

Not even deployed to staging yet Production next week at most Wait 2 weeks at least (I gotta monitor the RAM usage Update 1: Deployed to production, but since RAM...

Tested with `400,800,1600,3200,6400` and too much memory was used  Disabled next week and try with less refork (probably default value) the week after

Not seeing too much memory saving before/after enabling `mold_worker`... Will run for a few more weeks   Update 1:...

I guess the key object is the issue Code to reproduce: ```ruby namespace_str = "namespaceee" namespace_regexp = %r{^#{namespace_str}\:} "abce\xC3".match(namespace_regexp) ```

Need more people to report the same issue to analyze what causes this key value If it's user (dev) input or from other libraries then I prefer fixing at the...