673189 - Consider discarding cold jitted regexps

Status: RESOLVED DUPLICATE of bug 634654

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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.

Comment 1

[Nicholas Nethercote [inactive]]

Do we not already do that?  AFAICT normal code and regexp code both get allocated out of the same ExecutableAllocator (the one in JaegerCompartment).

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Chris Leary [:cdleary] (not checking bugmail)]

(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.

Comment 4

[Jesse Ruderman]

Compiled regexps should also be discarded upon memory-pressure.

Comment 5

[Chris Leary [:cdleary] (not checking bugmail)]

(In reply to comment #4)
> Compiled regexps should also be discarded upon memory-pressure.

Does anything in the JS engine currently do that?

Comment 6

[Nicholas Nethercote [inactive]]

> > Compiled regexps should also be discarded upon memory-pressure.
> 
> Does anything in the JS engine currently do that?

Not AFAIK.

Comment 7

[Brian Hackett [Laid off!]]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Just to put numbers to this, right now my system compartment contains 152MB of regexp jitcode....

Comment 9

[Chris Leary [:cdleary] (not checking bugmail)]

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.

Comment 10

[Nicholas Nethercote [inactive]]

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?

Comment 11

[Chris Leary [:cdleary] (not checking bugmail)]

Bug 634654 purges the RegExpPrivate code on each GC.