I'd like to GC regular expression guts (instead of refcounting them, as we do now), cache the results of regular expression compilation with a weakref cache on the compartment, use lazy regexp compilation (to avoid parse time overhead), and use the newfound lazy powers to evict code from cold regexp guts at GC time. Most of these are already filed, but I felt that all this yearning inside of me *deserved* to be expressed in the form of a meta-bug.
OS: Linux → All
Hardware: x86_64 → All
Why switch from refcounting to gc for these leaf objects? Not saying it's a bad idea, but just trying to understand the reasoning.
(In reply to comment #1) Less opportunities to have faulty refcounting is a good enough reason for me, TBH. With a flexible-sized GC capability (in joyous times to come) they could contain their bytecode, so it'd be nice to head in this direction anyway.
No longer blocks: 672064
No longer depends on: 693858
No longer depends on: 661974
Mass-reassigning cdleary's bugs to default. He won't work on any of them, anymore. I guess, at least. @cdleary: shout if you take issue with this.
Assignee: cdleary → general
Status: ASSIGNED → NEW
All the bugs this bug depends on are closed, and even bug 654820 is closed now. Can this bug be closed now?
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.