Bug 78876 – Fine-grained JSC JIT code profiling at the function level

• Status: NEW
• Component: JavaScriptCore

[Yuqiang Xian]

This tends to add fine-grained JIT code profiling support with which we can get more detailed information at the function level. A symbol table is created in CodeProfile to manipulate the symbols (consisting of function names (if available) and line numbers), and the samples on different JIT functions are reported separately.

Patch forthcoming.

[Yuqiang Xian]

Created attachment 127520 [details]
proposed patch

[Gavin Barraclough]

Comment on attachment 127520 [details]
proposed patch

I think there is a problem with this in that the string concatenation may trigger a malloc, and the main thread may be suspended holding the malloc heap lock, resulting in deadlock.
I do think we'll want to get more detailed information out of the profiler, but I'm not sure this is the right approach – rather, I think we may want a way to retain all code blocks while profiling, and to lazily manage mapping sampled PCs back to the byte code offset (line number, etc), from the main thread once sampling is complete.

[Yuqiang Xian]

Created attachment 127585 [details]
updated patch

Gavin, thanks for pointing out the problem.

Yes, as you mentioned, I think we should do the JIT symbol mapping stuffs after sampling. And I think when the profiling is ended and the profile is reported the CodeBlocks _should_ be alive. As the CodeProfiling stuff will be cleaned-up when we get out of evaluate(), while the CodeBlocks are allocated in the heap which are supposed to be reclaimed later. So this new patch is based on this assumption.

Example profiling output:

<CodeProfiling /mnt/supplement/kraken/tests/kraken-1.1/ai-astar.js:1>
Total samples: 8354
    8259: [[DFGJIT]] : search (Lines: 48-118) (8259 stack top)
      82: [[EngineCode]] (0 stack top)
          82: <unknown> (82 stack top)
      10: [[DFGJIT]] : neighbors (Lines: 125-143) (10 stack top)
       1: [[DFGJIT]] : findGraphNode (Lines: 7-12) (1 stack top)
       1: [[DFGJIT]] : init (Lines: 38-47) (1 stack top)
       1: [[BaselineOSR]] : init (Lines: 38-47) (1 stack top)
</CodeProfiling /mnt/supplement/kraken/tests/kraken-1.1/ai-astar.js:1>

[Yuqiang Xian]

Sorry but please just ignore my last comment. The Code blocks may be deleted during the script evaluation because of GC - which is reasonable in a normal run. Should we disallow code GC when profiling is enabled?

[Gavin Barraclough]

(In reply to comment #4)
> Sorry but please just ignore my last comment. The Code blocks may be deleted during the script evaluation because of GC - which is reasonable in a normal run. Should we disallow code GC when profiling is enabled?

I think we may want to disable recovery of the JIT code buffers, yes.  I guessing we don't need to keep any JS heap GC objects alive, but we'll want to retain the code blocks of executables that are destroyed.  I believe we already have a mechanism to keep code blocks alive, where they have been jettisoned from an executable, but may still be on the stack.  We may be able to reuse the same mechanism, but I haven't looked into this.

[Yuqiang Xian]

Created attachment 128681 [details]
patch updated

Patch updated.

we retain the code blocks and the executable memory in order to map the address to the JS function and line numbers correctly.
Also, the children map of a ProfileTreeNode needs to be reference counted to avoid dangling pointers due to map expansion.

[Yuqiang Xian]

Hi Gavin, how do you think about the updated patch?
Thanks.

[Yuqiang Xian]

Created attachment 145922 [details]
Rebase

[Build Bot]

Comment on attachment 145922 [details]
Rebase

Attachment 145922 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12895786

[Build Bot]

Comment on attachment 145922 [details]
Rebase

Attachment 145922 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/12906493

[Gyuyoung Kim]

Comment on attachment 145922 [details]
Rebase

Attachment 145922 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/12900696

[Yuqiang Xian]

Created attachment 145938 [details]
o... the previous one is wrongly rebased.. this one please

[Anders Carlsson]

Comment on attachment 145938 [details]
o... the previous one is wrongly rebased.. this one please

Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.