Closed Bug 673189 Opened 13 years ago Closed 13 years ago

Consider discarding cold jitted regexps

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 634654

People

(Reporter: bzbarsky, Assigned: cdleary)

References

Details

(Whiteboard: [MemShrink:P1])

See discussion in bug 670689. We discard other jitcode if it's not used for a while; it might make sense to do so for regexps too.
Do we not already do that? AFAICT normal code and regexp code both get allocated out of the same ExecutableAllocator (the one in JaegerCompartment).
Whiteboard: [MemShrink]
Yes, but we never deallocate the regexp code, so the pools that happen to have a compiled regexp in them can never go away until the actual RegExp object goes away. At least if I read the code right.
(In reply to comment #2) > pools that happen to > have a compiled regexp in them can never go away until the actual RegExp > object goes away That's my understanding as well.
Compiled regexps should also be discarded upon memory-pressure.
Whiteboard: [MemShrink] → [MemShrink:P1]
(In reply to comment #4) > Compiled regexps should also be discarded upon memory-pressure. Does anything in the JS engine currently do that?
> > Compiled regexps should also be discarded upon memory-pressure. > > Does anything in the JS engine currently do that? Not AFAIK.
The TI branch discards most inference data and all mjit code on every GC when inference is enabled, which sort of counts in this category. I think that compilation is cheap for both regexps and jitcode (now that we compile warm code and not all code; do regexps warm up before compiling?) and I doubt anyone would notice if all regexp jitcode was purged on GC (maybe good to measure regexp compilation time looking at real websites). The performance characteristics of this sort of approach will only improve as we get a generational GC and do major collections less frequently.
Just to put numbers to this, right now my system compartment contains 152MB of regexp jitcode....
With the laziness (bug 673188) and caching (bug 634654) we've eliminated the overhead from run-zero-times regexps and the new-regexp-with-an-atom-in-a-loop, but this is what should really fix the symptoms seen in comment 8. Trace hook for RegExpObject can drop the refcount on its private, if the private is present (in light of the new laziness). This will also validate refcounting correctness (i.e. bug 654820), since there should exist zero RegExpPrivates in the cache after GC.
Depends on: 673188
Assignee: general → cdleary
Status: NEW → ASSIGNED
cdleary, I see that bug 634654 just landed on mozilla-inbound, is this bug next? :) What will the approach be -- discard based on a counter? Discard on every GC like bhackett suggests?
Bug 634654 purges the RegExpPrivate code on each GC.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.