1276261 - Look into whether JitcodeMap skiplist manipulation could be reduced.

Status: RESOLVED DUPLICATE of bug 1801875

(Core :: JavaScript Engine: JIT, defect, P5)

Description

[Kannan Vijayan [:djvj]]

Randall Jesup commented in a secure bug:
> I threw the printf in.  Loading huffingtonpost into a
> tab, and letting it sit there (debug build) hits the
> generator 100000 times every few minutes - with one,
> idle (though fancy) page loaded.  Wow.....  Still not
> sure, but this may mean it could hit 0's occasionally.
> 
> This also says "this is a potential perf hotspot".

The jitcodemap implementation adds an entry for every piece of jitcode that is compiled - either baseline, ion, or ion IC stubs.

Ideally, the overhead of inserting an element into the skiplist for every jitcode compile should be quite low, since each of those inserts only happens when a corresponding codegen + compile occurs, and these are associated with slowpaths anyway.

If this intuition is wrong, and the overhead is not worth it, we should look into approaches where we only add items to the skiplist when profiling is turned on.

My suspicion is that the "hotspot" here is not actually a big deal.  If we're inserting things into the skiplist 10k times in a few minutes, it means we're doing jit-compilation 10k times in that same period.  THAT seems like a more likely target for perf optimization - identify and eliminate the cause of the compilation.

Shu's suggestion of a fix was this:
> Any ideas on how to make this less hot? The comment
> suggests that we allocate a JitcodeGlobalEntry for
> every baseline compile because we can't do this
> post-hoc for on-stack scripts.
> 
> I'm actually not sure why that is. When we flip on
> profiling, can't we just take a list of all the
> on-stack scripts and make JitcodeGlobalEntries for
> them then?

This seems like a reasonable approach if we decide to take it.  My only comment is that we wouldn't just walk all the on-stack jitscripts to add entries for them, we'd have to walk all jitcode across the system and add entries for them.  This is because if we don't, for example, add an entry for an Ion IC stub that's not on stack, then we may well enter that IC stub after profiling has been turned on, and then run into a stackwalk where we see native code address that doesn't map into the IC.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Going to resolve this is a dupe of the recent datastructure replacement.