941830 - Extend asm.js compiled code caching to Workers

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Luke Wagner [:luke]]

Bug 929236 adds general caching support the main JSRuntime, but not Worker JSRuntimes.  I think this is mostly just a matter of calling JS_SetAsmJSCacheOps in CreateJSContextForWorker.  The only challenge is that nsContentUtils::GetObjectPrincipal doesn't work on a worker global object, so we'll have to derive the nsIPrincipals in a different way.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Well prinicpals aren't threadsafe, so we probably need something more complicated here.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Also is asm.js performance really important for b2g?

Comment 3

[Andrew McCreight [:mccr8]]

Yeah, I guess not. :P

Comment 4

[Luke Wagner [:luke]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #1)
The runnables in bug 929236 that handle caching already are quite careful to only refct/use the nsIPrincipal from the main thread.  The nsIPrincipal associated with the worker will be extracted on the main thread, so this should fit right in.

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #2)
> Also is asm.js performance really important for b2g?

In general, yes, it is.  If you're refering to asm.js-caching-in-workers-on-b2g, then no so much, for now.  IIUC though, a major goal for the upcoming year is to be able to run a complete game (with WebGL, IndexedDB, etc) from within a worker (thereby allowing sync FS access thereby avoiding Emscripten's VFS thereby significantly reducing memory pressure), so asm.js caching would matter quite a lot then too.

Comment 5

[Luke Wagner [:luke]]

Attachment: caching-in-workers

Pretty simple patch.  The unfortunate wart is GetPrincipalDontAssertMainThread() (happy to entertain a more appropriate name).  This seems justified, though, since we're effectively already doing the same thing in the non-worker case (accessing GetObjectPrincipal(obj) off the main thread) and it doesn't seem valuable to jump through a bunch of hoops to access the worker's GetPrincipal from the main thread when we already handle the nsIPrincipal very carefully to avoid any AddRef/Release/etc off the main thread.

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 8339609 [details] [diff] [review]
caching-in-workers

Review of attachment 8339609 [details] [diff] [review]:
-----------------------------------------------------------------

This looks great!

::: dom/workers/moz.build
@@ +59,5 @@
>      '/content/events/src',
>      '/xpcom/build',
>  ]
>  
> +include('/ipc/chromium/chromium-config.mozbuild')

Hm, is this needed? Why?

::: js/xpconnect/tests/mochitest/test_asmjs3.html
@@ +24,5 @@
> +  ok(code.length > 10000);
> +
> +  var workerStr = 'var code = "' + code + '"; eval(code); eval(code)';
> +  var blob = new Blob([workerStr], {type:"application/javascript"});
> +  var w = new Worker(URL.createObjectURL(blob));

Hm, at some point you need to call URL.revokeObjectURL in order to avoid leaking (probably right before you call finish()).

Comment 7

[Luke Wagner [:luke]]

(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #6)
> > +include('/ipc/chromium/chromium-config.mozbuild')

IIRC, "ipc/IPCMessageUtils.h", included by AsmJSCache.h, requires it.

> Hm, at some point you need to call URL.revokeObjectURL in order to avoid
> leaking (probably right before you call finish()).

Oh wow, really?  I had hoped that all those object URLs were tied to the lifetime of the page (globa/document) and so when the test completed, they'd get freed.  But I guess it's not that easy since the point is you can pass object URLs anywhere.  Is there any limit on the lifetime of object URLs or can a single page permanently leak a Blob for all time?!

Comment 8

[Luke Wagner [:luke]]

(In reply to Luke Wagner [:luke] from comment #7)
> Oh wow, really?  I had hoped that all those object URLs were tied to the
> lifetime of the page (globa/document) and so when the test completed, they'd
> get freed.  But I guess it's not that easy since the point is you can pass
> object URLs anywhere.  Is there any limit on the lifetime of object URLs or
> can a single page permanently leak a Blob for all time?!

I looked into this a bit more and found this bit on MDN (https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Using_object_URLs):

'While they are released automatically when the document is unloaded, if your page uses them dynamically, you should release them explicitly by calling window.URL.revokeObjectURL():'

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Yeah, you only need to explicitly revoke them if you want to do it before the end of the test.  They are automatically revoked when the document unloads.

Comment 10

[Luke Wagner [:luke]]

Great!
https://hg.mozilla.org/integration/mozilla-inbound/rev/e7a05036921b

Comment 11

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #9)
> Yeah, you only need to explicitly revoke them if you want to do it before
> the end of the test.  They are automatically revoked when the document
> unloads.

Oops, sorry about that!

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e7a05036921b