1397718 - Still missing some JS frames

Status: NEW

(Core :: Gecko Profiler, defect, P3)

Description

[Markus Stange [:mstange]]

Continued from bug 1393046.

(In reply to Alexandre Poirot [:ochameau] from comment #12)
> It looks like it fixed most JS stacks but still miss the first one.
> See this profile: https://perfht.ml/2exgP3a
> This is with the same STR as comment 0.
> 
> In this profile slice, you can see that the first half contains no JS stack
> if you filter only JS.
> You can see that the second half contains JS frames.
> But there is JS executed in both halfs!
> 
> In this first half, if you exand on PBrowser::Msg_LoadRemoteScript,
> as before you will see some calls to EnterBaseline followed with unresolved
> addresses.

(In reply to Alexandre Poirot [:ochameau] from comment #13)
> (I used artifact builds against latest tip from today)

(In reply to Alexandre Poirot [:ochameau] from comment #14)
> Here is another case, which is different as it is in parent process and
> happening late (not in any kind of startup).
>   https://perfht.ml/2eyD9cI
> If you expand that tree you will see valid JS frames from react.js and a
> bunch of unresolved addresses.
> 
> The STR is the same, but the piece of code is harder to spot, from the
> overall profile, look for setCanReader and you will find it under
> updateChildren calls from react.

Comment 1

[Alexandre Poirot [:ochameau]]

I suspect these missing frame to hide the performance issue I'm chasing in bug 1396633.

If you expand the call tree under "setCanRender" JS function:
  https://perfht.ml/2h3HPvK
You will see a bunch of unresolved symbols.
That that very precise call tree is exactly the performance issue I'm looking into and can't easily explain.
I'm wondering if there is some xpconnect wrappers involved here, or if that's a JS proxy we have that introduces extra slowness.
(We do use "Proxy()" to monkey patch React...)

If there is anything I can do to help chase this down, please tell me!

Comment 2

[Markus Stange [:mstange]]

The unresolved symbols without a library name next to them are JIT frames: This is code that was generated at runtime. It can't really be symbolicated with a C++ function name because it's not a C++ function. The JS function names for the JIT code get added as separate call stack frames next to the JIT frames. (You could argue that the JIT frames should be replaced instead.)

I don't know if we get separate JS stack frames for proxies.

I'm not sure that there's any hidden information in the setCanRender call tree. The stacks and the time that each function takes seems to make sense, or at least I don't see any evidence that it doesn't.

Comment 3

[Greg Tatum [:gregtatum]]

If you switch over to the timeline view, the flame chart will show be able to show which JS implementation was used. Any code that includes unsymbolicated frames are only only listed below JS JIT frames. I'll do some follow-ups to see if we can handle this type of thing better.

Comment 4

[Greg Tatum [:gregtatum]]

I filed a discussion bug for handling those unsymbolicated frames better in perf.html: https://github.com/devtools-html/perf.html/issues/586