Single-threaded compartments

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
9 years ago
8 years ago

People

(Reporter: jorendorff, Assigned: jorendorff)

Tracking

Other Branch
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [evang-wanted])

(Assignee)

Description

9 years ago
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.
(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
(Assignee)

Comment 2

9 years ago
(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?
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
(Assignee)

Comment 4

9 years ago
   <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.
Whiteboard: [evang-wanted]

Updated

9 years ago
Assignee: general → jorendorff

Updated

9 years ago
blocking2.0: --- → beta1+
Bug 566951 is relevant, has patch.

/be

Updated

9 years ago
blocking2.0: beta1+ → beta2+

Updated

8 years ago
blocking2.0: beta2+ → betaN+
Has this bug been fixed?
I'm going to assume this is an obsolete bug and has been obviated by compartments work since May.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.