about:memory reporter for string chars

RESOLVED FIXED in mozilla2.0b9

Status

()

defect
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: shaver, Unassigned)

Tracking

Trunk
mozilla2.0b9
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(This is a bit ugly, but I want to keep the patch minimal until after b9 at least, probably after FF4.)
Attachment #501989 - Flags: review?
Comment on attachment 501989 [details] [diff] [review]
track string-chars usage

Luke knows strings!
Attachment #501989 - Flags: review? → review?(lw)
Looks generally good.  What about making a cx->allocStringChars and cx->freeStringChars, doing all the accounting in just those two, and having all the sites you've modified in this patch call those?
As a follow-up, I want to add API for accessors to JSRuntime instead of the direct banging, and move all the stats into the same substruct.  Would you let me do it there? :-)

Updated

9 years ago
Attachment #501989 - Flags: review?(lw) → review+
r+ with comment 3 as a follow up.
http://hg.mozilla.org/tracemonkey/rev/7b83f88c9e2c
http://hg.mozilla.org/mozilla-central/rev/7b83f88c9e2c
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b9
This creates loads of races on JSRuntime::stringMemoryUsed.  Is that
known about / acceptable?

Possible data race during read of size 4 at 0x5fccba4 by thread #4
   at 0x4DF790: js_NewString(JSContext*, unsigned short*, unsigned long) (jsstr.cpp:3417)
   by 0x42DA9C: JSStructuredCloneReader::readString(unsigned int) (jsclone.cpp:637)
   by 0x42EE29: JSStructuredCloneReader::startRead(js::Value*) (jsclone.cpp:712)
   by 0x42F66B: JSStructuredCloneReader::read(js::Value*) (jsclone.cpp:842)
   by 0x42F7EC: js::ReadStructuredClone(JSContext*, unsigned long const*, unsigned long, js::Value*, JSStructuredCloneCallbacks const*, void*) (jsclone.cpp:66)
   by 0x4133E1: JS_ReadStructuredClone (jsapi.cpp:5531)
   by 0x40E39C: js::workers::InitEvent::process(JSContext*) (jsworkers.cpp:298)
   by 0x40D25E: js::workers::Worker::processOneEvent() (jsworkers.cpp:1118)
   by 0x40D9A9: js::workers::WorkerQueue::work() (jsworkers.cpp:1006)
   by 0x40FF8D: js::workers::ThreadPool::start(void*) (jsworkers.cpp:461)
   by 0x5077EC2: _pt_root (ptthread.c:189)
   by 0x4C2CBE7: mythread_wrapper (hg_intercepts.c:221)

 This conflicts with a previous write of size 4 by thread #3
   at 0x4DF790: js_NewString(JSContext*, unsigned short*, unsigned long) (jsstr.cpp:3417)
   by 0x42DA9C: JSStructuredCloneReader::readString(unsigned int) (jsclone.cpp:637)
   by 0x42EE29: JSStructuredCloneReader::startRead(js::Value*) (jsclone.cpp:712)
   by 0x42F66B: JSStructuredCloneReader::read(js::Value*) (jsclone.cpp:842)
   by 0x42F7EC: js::ReadStructuredClone(JSContext*, unsigned long const*, unsigned long, js::Value*, JSStructuredCloneCallbacks const*, void*) (jsclone.cpp:66)
   by 0x4133E1: JS_ReadStructuredClone (jsapi.cpp:5531)
   by 0x40E39C: js::workers::InitEvent::process(JSContext*) (jsworkers.cpp:298)
   by 0x40D25E: js::workers::Worker::processOneEvent() (jsworkers.cpp:1118)

 Address 0x5fccba4 is 2372 bytes inside a block of size 2376 alloc'd
   at 0x4C26E2C: calloc (vg_replace_malloc.c:467)
   by 0x412DFD: js_calloc (jsutil.h:213)
   by 0x417D81: JS_Init (jsapi.cpp:757)
   by 0x40A200: main (js.cpp:5529)
You need to log in before you can comment on or make changes to this bug.