Closed Bug 697332 Opened 13 years ago Closed 3 years ago

Avoid allocating for the setPropertyAsAString() calls in the feed processor

Categories

(Core :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: n.nethercote, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [MemShrink:P2])

(Spun off from bug 697041.)

DMD saw some reports like this:

Unreported: 1,169,360 (cumulative: 522,935,088) bytes in 2,595 heap block(s) in record 54 of 27713:
 Requested bytes unreported: 963,290 / 963,290
 Slop      bytes unreported: 206,070 / 206,070
   at 0x402A063: malloc (vg_replace_malloc.c:263)
   by 0x403C044: moz_malloc (mozalloc.cpp:113)
   by 0x7A71BB9: nsStringBuffer::Alloc(...) (nsSubstring.cpp:209)
   by 0x7A71F45: nsAString_internal::MutatePrep(...) (nsTSubstring.cpp:162)
   by 0x7A72018: nsAString_internal::ReplacePrepInternal(...) (nsTSubstring.cpp:198)
   by 0x7A718F3: nsAString_internal::ReplacePrep(...) (nsTSubstring.h:685)
   by 0x7A72445: nsAString_internal::Assign(...) (nsTSubstring.cpp:335)
   by 0x7A725F1: nsAString_internal::Assign(...) (nsTSubstring.cpp:396)
   by 0x6774881: nsString::nsString(...) (nsTString.h:99)
   by 0x7A1D970: nsVariant::SetFromAString(...) (nsVariant.cpp:1480)
   by 0x7A1E647: nsVariant::SetAsAString(...) (nsVariant.cpp:2043)
   by 0x7A0CD4D: nsHashPropertyBag::SetPropertyAsAString(...) (nsHashPropertyBag.cpp:288)
   by 0x7A682DC: NS_InvokeByIndex_P (xptcinvoke_x86_64_unix.cpp:195)
   by 0x73AD83D: XPCWrappedNative::CallMethod(...) (XPCWrappedNative.cpp:2907)
   by 0x73B915B: XPC_WN_CallMethod(...) (XPCWrappedNativeJSOps.cpp:1553)
   by 0x7EEEFD8: js::InvokeKernel(...) (jscntxtinlines.h:297)
   by 0x7F06AAB: js::Interpret(...) (jsinterp.cpp:4002)
   by 0x7EEECE3: js::RunScript(...) (jsinterp.cpp:584)
   by 0x7EEF103: js::InvokeKernel(...) (jsinterp.cpp:647)
   by 0x7E6A8AA: js::Invoke(...) (jsinterp.h:148)

bz says this is from the feed processor, and that the allocation may be avoidable, depending on what the JSString looks like.

Steps to reproduce:  
- Create a new profile, and add these feeds to the bookmarks toolbar:

 http://www.bbc.co.uk/go/rss/int/news/-/news/
 http://bishophill.squarespace.com/blog/rss.xml
 http://www2.politicalbetting.com/index.php/feed/
 http://newsrss.bbc.co.uk/rss/sportonline_uk_edition/front_page/rss.xml
 http://www.spectator.co.uk/coffeehouse/index.txml
 http://feeds2.feedburner.com/guidofawkes
 http://www.iaindale.com/feed
 http://feeds.feedburner.com/arseblognews?format=xml
 http://noconsensus.wordpress.com/feed/

- Run the browser.  That's it.  bz, I guess you can set a breakpoint on SetPropertyAsAString and wait until it's hit.
Blocks: 692748
So what I had _thought_ we could do is look at the passed-in JSString in XPConnect and avoid an allocation if it's an external string of type sDOMStringFinalizerIndex (because then we know it wraps a stringbuffer and can just refcount it directly).

I have the JSAPI end of that done (something that returns a const jschar* if str is an external string of the right type), but actually figuring out where to plug that into XPCConvert is making my eyes bleed....  and Luke had a better plan for avoiding copying at the JS->XPCOM transition in general, so maybe we should just make this bug dependent on that one.
For reference, the JS->XPCOM string-sharing bug is bug 686989.
Depends on: 686989
Whiteboard: [MemShrink] → [MemShrink:P2]

No action in 9 years, closing.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.