Closed Bug 623281 Opened 14 years ago Closed 14 years ago

about:memory reporting for method JIT code space usage

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: shaver, Unassigned)

References

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file, 2 obsolete files)

Seems to work, in shell and browser. Shows us using ~17M on gmail, which mostly goes away after it closes, similarly on techcrunch. It doesn't account for allocator fragmentation costs, though, so I'll do another round later.
Attachment #501378 - Flags: superreview?
Attachment #501378 - Flags: review?(dvander)
Attachment #501378 - Flags: superreview? → superreview?(vladimir)
Comment on attachment 501378 [details] [diff] [review] memory reporter, only tested with default debug config ignoring dwrite/configure.in/etc. stuff, memory reporter wiring looks fine
Attachment #501378 - Flags: superreview?(vladimir) → superreview+
Fixed the misdiff, still learning how to use bookmarks sorry.
Attachment #501378 - Attachment is obsolete: true
Attachment #501379 - Flags: review?(dvander)
Attachment #501378 - Flags: review?(dvander)
finishThisUp() should use the new nonCodeSize() function! > cx->runtime->mjitCodeSize -= jscr->nonCodeSize() + jscr->codeSize(); These names are confusing -- "codeSize" has two different meanings. In jscr->codeSize() it's just the main code, excluding ICs and all that extra stuff. In mjitCodeSize it includes the ICs. This is a good feature, BTW, I think it should go into Fx 4.0. I'm still worried about bug 598466 and bug 615199.
finishThisUp can't use the nonCodeSize function, though I thought that too: it needs to calculate the JITScript size in order to allocate it. I thought about initializing the JITScript on the stack, using codeSize, and then copying it over, but I wasn't sure it was worth it. Basically all the names in this patch are terrible, though; lemme ponder that a bit.
(In reply to comment #4) > finishThisUp can't use the nonCodeSize function, though I thought that too: it > needs to calculate the JITScript size in order to allocate it. Oh, I see; it's because of e.g. mics.length() vs nMICs. A comment in each place saying "keep this in sync with the other place" would be good, then. BTW, is this patch against an oldish version? nMapPairs doesn't exist any more; that code has been changed a bit lately.
I have such a comment above the code in finishThisUp, but I'll add one on codeSize, too. It's against yesterday's m-c, because I'm a chump. I'll rebase to tm.
(In reply to comment #5) > BTW, is this patch against an oldish version? nMapPairs doesn't exist any > more; that code has been changed a bit lately. I still see nNmapPairs in JITScript as of 6a5b1f1a2296 ?
Attachment #501379 - Attachment is obsolete: true
Attachment #501568 - Flags: review?(dvander)
Attachment #501379 - Flags: review?(dvander)
Comment on attachment 501568 [details] [diff] [review] memory reporter, only tested with default debug config, updated to tm >+ /* Please keep in sync with JITScript::nonCodeBytes! */ It's not called nonCodeBytes any more! > size_t totalBytes = sizeof(JITScript) + > sizeof(NativeMapEntry) * nNmapLive + I know you are avoiding refactoring finishThisUp(), but maybe totalBytes and totalSize could be renamed to use the main/aux naming convention? That's only a handful of lines to change. >+/* Please keep in sync with Compiler::FinishThisUp. */ lower case 'f' in finishThisUp. </nitpicking>
Comments fixed locally, thanks. I'll let dvander weigh in on the totalSize/totalBytes renaming, if he likes this approach at all.
Attachment #501568 - Flags: review?(dvander) → review+
I recommend also taking the chaser http://hg.mozilla.org/tracemonkey/rev/8d7836a659e8 so that you can build.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 624350
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: