558866 - Single-threaded compartments

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Jason Orendorff [:jorendorff]]

Bug 558861 has us dividing the JS heap into compartments to support faster per-tab or per-Worker GC.

This bug is to eliminate some remaining JS_THREADSAFE overhead by restricting each compartment to a single thread at a time. We can eliminate:

  - the remaining locking around allocation of GC things
  - the titles and ownercx checks on native JSObjects
  - Worker threads having to wait for main-thread GC

The hard part of this bug is to provide some sane migration path for the relatively small number of extensions and embeddings using shared-everything multithreading. Sharing isolated objects (just data) across threads is easy to support. Sharing script functions will be harder to figure out. I don't have the answer yet, but we'll get there.

Comment 1

[Brendan Eich [:brendan]]

(In reply to comment #0)
> The hard part of this bug is to provide some sane migration path for the
> relatively small number of extensions and embeddings using shared-everything
> multithreading. Sharing isolated objects (just data) across threads is easy to
> support.

Isn't sharing going to require the "becomes" proxy idea from

http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_frm/thread/6405c47e4342deef/d95cf84e24e55091?#d95cf84e24e55091

?

> Sharing script functions will be harder to figure out. I don't have
> the answer yet, but we'll get there.

What's the issue for functions per se?

/be

Comment 2

[Jason Orendorff [:jorendorff]]

(In reply to comment #1)
> What's the issue for functions per se?

Well, suppose a function is shared among compartments such that it can be executed in two compartments concurrently. Then the function's global ends up being shared. The same goes for other objects along the function's scope chain, such as Call objects. I think we'd rather not go there--right?

Comment 3

[Brendan Eich [:brendan]]

The Ice-9 disaster can happen any number of ways. Functions are one, but the parent slot is universal (bug on file on that, IIRC). The request model lets an ST object graph transitively become an MT proxy graph lazily, as each edge from an MT proxy to a ST thing is traversed by a request.

I don't see why functions are special in this regard. Sauce for the goose.

/be

Comment 4

[Jason Orendorff [:jorendorff]]

   <jorendorff> brendan: Functions are special because the objects they expose
                along those edges are special
   <jorendorff> brendan: Call, Block, With, DeclEnv, the global
      <brendan> jorendorff: ah, clones
      <brendan> yes
   <jorendorff> we want to optimize how running code accesses those
   <jorendorff> there's some tension between that and sharing
      <brendan> jorendorff: generally, we want to avoid proxying some objects
   <jorendorff> yes
      <brendan> sharing compiler-created functions could be ok
   <jorendorff> ok, I believe that
      <brendan> not compile-n-go ones of course
      <brendan> that would be a bug
   <jorendorff> sure
      <brendan> jorendorff: ok, good point -- want to record in the bug (and
                take it? ;-)

Not taking this yet because I'm not quite ready to work on it
yet. Soon though.

Comment 5

[Brendan Eich [:brendan]]

Bug 566951 is relevant, has patch.

/be

Comment 6

[David Mandelin [:dmandelin]]

Has this bug been fixed?

Comment 7

[David Mandelin [:dmandelin]]

I'm going to assume this is an obsolete bug and has been obviated by compartments work since May.