Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Previously the regmatch_info struct was allocated as a local var on the C stack, while some extra state (only needed for regexes having (?{})) was malloced (as a regmatch_eval_state struct) as needed - and a destructor set up to clean it up afterwards. This being because the stuff being cleaned up couldn't be allocated on the C stack as it needed to hang around after a croak(). Reorganise this so that: * regmatch_info is on the C stack as before. * a new struct, regmatch_info_aux is allocated within the first slot of the regmatch_state stack, for fields which must always exist but which need cleanup afterwards. This is currently unused, but will be shortly. * a new struct, regmatch_info_aux_eval (which is just a renamed regmatch_eval_state struct), is optionally allocated in the second slot of regmatch_state. This is logically part of regmatch_info_aux, except that splitting it in two stops it being too large to fit in a regmatch_state slot (we can fit it in two instead). (The second and third structs aren't allocated when we're intuit() rather than regexec()). Doing it like this simplifies allocation and cleanup: there's no need for a malloc(), and we are already going to allocate a slab's worth of regmatch_state slots, so using an extra one of two of them is effectively free; and the cleanup just requires calling a single overall destructor. In the next few commits, more of the regexec() state setup and tear-down will be integrated into this new regime. And in particular, the new regmatch_info_aux struct will give us somewhere to hang things like PL_reg_poscache once it stops being global (it being local state that needs cleanup).
- Loading branch information
Showing
2 changed files
with
109 additions
and
68 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters