623915 - about:memory reporter for string chars

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mike Shaver (:shaver emeritus)]

Attachment: track string-chars usage

(This is a bit ugly, but I want to keep the patch minimal until after b9 at least, probably after FF4.)

Comment 1

[Mike Shaver (:shaver emeritus)]

Comment on attachment 501989 [details] [diff] [review]
track string-chars usage

Luke knows strings!

Comment 2

[Luke Wagner [:luke]]

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?

Comment 3

[Mike Shaver (:shaver emeritus)]

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? :-)

Comment 4

[Luke Wagner [:luke]]

r+ with comment 3 as a follow up.

Comment 5

[Mike Shaver (:shaver emeritus)]

http://hg.mozilla.org/tracemonkey/rev/7b83f88c9e2c
http://hg.mozilla.org/mozilla-central/rev/7b83f88c9e2c

Comment 6

[Julian Seward [:jseward]]

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)