970878 - We need a way to fill a JSString from another thread.

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

(Sister to bug 970253)

Consider the following use case: a main thread JS client needs to read a string from some source, using OMT IO (e.g. OS.File, DOMFileReader). For this but, the IO worker is C++-based, not a DOM/Chrome Worker.

At the moment, the algorithm is the following:
1. main thread posts request to IO thread;
2. IO thread reads contents and decodes string to a C++ buffer;
3. IO main thread copies C++ buffer to JS string.

Whenever JS strings are very large (e.g. 50mb of Session Restore), step 3. can cause jank. It would be very useful to be able to allocate and fill the JSString object from the IO thread and somehow transfer its ownership to the main thread.

Comment 1

[Boris Zbarsky [:bzbarsky]]

JS_NewExternalString already exists, no?  

Furthermore, if you're using XPCOM strings with refcounted buffers and the normal bindings/XPConnect functionality for converting an XPCOM string to a JS string, you should be getting the no-copy behavior for free.

If, on the other hand, your XPCOM string is owning a raw buffer as opposed to a refcounted one, then right now we have no fast path for that case.  We could add one, though.

Comment 2

[Boris Zbarsky [:bzbarsky]]

But it would just be simpler if you arranged for your XPCOM string to be using a refcounted buffer, of course.  As long as you don't Adopt() into it, that's the default behavior anyway.

Oh, and all that only applies to Unicode XPCOM strings, of course.  If you're using 8-bit strings, then the JS engine _has_ to copy, because JSString's internal representation is 16-bit code units.

Comment 3

[David Teller [:Yoric] - still alive but not very active]

Ah, good to know. I wasn't aware of this function.

If using XPCOM, how can I be sure that I'm getting the no-copy behavior?

Comment 4

[Jason Orendorff [:jorendorff]]

Another way to do this is to JS_malloc the char buffer, fill it, then on the other thread call JS_NewUCString().

Comment 5

[Boris Zbarsky [:bzbarsky]]

> If using XPCOM, how can I be sure that I'm getting the no-copy behavior?

As long as you don't use Adopt() or getter_Copies and don't use an autostring, you'll get the no-copy behavior.  And even in the autostring case you'll get it for strings that are long.

> then on the other thread call JS_NewUCString()

Ah, right, I forgot that we do have an adopting JSString constructor.  So that's definitely an option too, depending on what you're doing, exactly.