Closed
Bug 850156
Opened 11 years ago
Closed 11 years ago
BaselineCompiler: Separate ion/baseline memory reporters for JIT code
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla22
People
(Reporter: jandem, Assigned: jandem)
References
Details
Attachments
(1 file)
25.58 KB,
patch
|
n.nethercote
:
review+
dvander
:
review+
|
Details | Diff | Splinter Review |
Right now we use IonCode so baseline code is reported under ion-code. njn suggested using different reporters for baseline and Ion code, and I agree that would be useful.
Assignee | ||
Comment 1•11 years ago
|
||
Adds two new memory reporters: code/other and code/baseline (and updates the other reporters so that they are in a "code" subtree). code/other is used for trampolines and VM wrappers. These will be used by baseline too so it's wrong to report them under either code/ion or code/baseline.
Attachment #723905 -
Flags: review?(n.nethercote)
Attachment #723905 -
Flags: review?(dvander)
Comment 2•11 years ago
|
||
Comment on attachment 723905 [details] [diff] [review] Patch Review of attachment 723905 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/assembler/jit/ExecutableAllocator.cpp @@ +49,5 @@ > + *ion = 0; > + *baseline = 0; > + *regexp = 0; > + *other = 0; > + *unused = 0; Six values is enough that this would benefit from getting its own struct, like ObjectsExtraSizes and TypeInferenceSizes. Feel free to do that if you want, but I won't insist. ::: js/xpconnect/src/XPCJSRuntime.cpp @@ +1881,5 @@ > > + RREPORT_BYTES(rtPath + NS_LITERAL_CSTRING("runtime/code/baseline"), > + nsIMemoryReporter::KIND_NONHEAP, rtStats.runtime.baselineCode, > + "Memory used by the Baseline JIT to hold the runtime's " > + "generated code."); You can remove "the runtime's " here and in the other cases.
Attachment #723905 -
Flags: review?(n.nethercote) → review+
Comment on attachment 723905 [details] [diff] [review] Patch Review of attachment 723905 [details] [diff] [review]: ----------------------------------------------------------------- Why OTHER_CODE instead of ION_CODE?
Attachment #723905 -
Flags: review?(n.nethercote)
Attachment #723905 -
Flags: review?(dvander)
Attachment #723905 -
Flags: review+
Comment 4•11 years ago
|
||
Comment on attachment 723905 [details] [diff] [review] Patch Review of attachment 723905 [details] [diff] [review]: ----------------------------------------------------------------- My r+ was overwritten, apparently.
Attachment #723905 -
Flags: review?(n.nethercote) → review+
Assignee | ||
Comment 5•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/40b366dc7fad (In reply to David Anderson [:dvander] from comment #3) > Why OTHER_CODE instead of ION_CODE? VM wrappers etc are used by both Ion and baseline, so I think it's clearer to report them under OTHER instead of ION.
Comment 6•11 years ago
|
||
ION_OR_BASELINE_CODE, maybe?
Comment 7•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/40b366dc7fad
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
You need to log in
before you can comment on or make changes to this bug.
Description
•