Use mayNotBeMainThread() for wrapper optimization

Use mayNotBeMainThread for wrapper optimization

DOMDataStore has overloaded methods (for Node*) that checks if we're in a main world by checking if isolated worlds exist, and returns a main world wrapper directly if they don't exist. Node is used because it can never be created in a worker world. 

This patch changes the main world check to checking if we're on the main thread (using mayNotBeMainThread) and if any non-main worlds have been created on the main thread (If there are no non-main worlds, we have to be in the main world). This way, we don't need Node.  

BUG=682322
Review-Url: https://codereview.chromium.org/2726593002
Cr-Commit-Position: refs/heads/master@{#455530}
Committed: https://chromium.googlesource.com/chromium/src/+/199953cd647ec50f5f07d9025e5a8ba6948f8079

[jbroman, 2017-02-28 18:50:17]

jbroman@chromium.org changed reviewers:
+ jbroman@chromium.org

[jbroman, 2017-02-28 18:50:18]

https://codereview.chromium.org/2726593002/diff/1/third_party/WebKit/Source/b...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp (right):

https://codereview.chromium.org/2726593002/diff/1/third_party/WebKit/Source/b...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:98:
workerWorldCreated = true;
This is accessed on multiple threads. Though the races is probably "benign"
here, this should use atomic access. Unfortunately std::atomic<bool> is still
not allowed in Chromium, so WTF::acquireLoad/WTF::releaseStore should do. (A
lock would work too, but this is a fairly simple case.)

If we do go this way, we might as well make it a counter, though (see the way
ThreadSafeRefCounted works). That should be no more expensive at the per-wrapper
level, but will at least mean that we can in principle go back to the fast path
when workers go away.

[adithyas, 2017-02-28 18:52:51]

Description was changed from

==========
Use isolatedWorldsOrWorkerExists()

BUG=682322
==========

to

==========
Use isolatedWorldsOrWorkerExists() for wrapper optimization

DOMDataStore has overloaded methods for Node that checked if isolated worlds
existed, and returs a main world wrapper directly if they don't exist. Node is
used because it can never be created in a worker world. This CL removes the
overloaded methods by just checking if isolated worlds have been created or a
worker world exists, and returning a main world wrapper if they both don't
exist.

BUG=682322
==========

[adithyas, 2017-02-28 18:52:52]

adithyas@chromium.org changed reviewers:
- jbroman@chromium.org

[adithyas, 2017-02-28 21:15:57]

Description was changed from

==========
Use isolatedWorldsOrWorkerExists() for wrapper optimization

DOMDataStore has overloaded methods for Node that checked if isolated worlds
existed, and returs a main world wrapper directly if they don't exist. Node is
used because it can never be created in a worker world. This CL removes the
overloaded methods by just checking if isolated worlds have been created or a
worker world exists, and returning a main world wrapper if they both don't
exist.

BUG=682322
==========

to

==========
Use isolatedWorldsOrWorkerExists() for wrapper optimization

DOMDataStore has overloaded methods (for Node*) that checks if isolated worlds
exist, and returns a main world wrapper directly if they don't exist. Node is
used because it can never be created in a worker world. This CL removes the
overloaded methods by just checking if isolated worlds or worker worlds
currently exist, and returning a main world wrapper if they both don't exist.

BUG=682322
==========

[adithyas, 2017-02-28 21:15:58]

adithyas@chromium.org changed reviewers:
+ haraken@chromium.org, jbroman@chromium.org

[haraken, 2017-03-01 01:19:24]

https://codereview.chromium.org/2726593002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h (right):

https://codereview.chromium.org/2726593002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h:72: static bool
isolatedWorldsOrWorkerWorldExist() {

This check needs to be super fast. So it might be heavy to call acquireLoad.

Another idea would be:

- Prepare only one global variable. "bool s_isolatedWorldOrWorkerExist".

- Flip the boolean flag true when the main thread creates a worker thread or an
isolated world.

That way we can avoid using an atomic operation.

[jbroman, 2017-03-01 03:04:56]

On 2017/03/01 at 01:19:24, haraken wrote:
>
https://codereview.chromium.org/2726593002/diff/20001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h (right):
> 
>
https://codereview.chromium.org/2726593002/diff/20001/third_party/WebKit/Sour...
> third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h:72: static bool
isolatedWorldsOrWorkerWorldExist() {
> 
> This check needs to be super fast. So it might be heavy to call acquireLoad.
> 
> Another idea would be:
> 
> - Prepare only one global variable. "bool s_isolatedWorldOrWorkerExist".
> 
> - Flip the boolean flag true when the main thread creates a worker thread or
an isolated world.
> 
> That way we can avoid using an atomic operation.

I'd be surprised if the single atomic load was sufficiently expensive. (And it
should get slightly better once we can make WTF atomics use the proper
intrinsics, probably by switching to std::atomic.) But yeah, setting the
variable on the main thread when a worker is created would solve that issue.

[adithyas, 2017-03-01 20:07:10]

On 2017/03/01 at 03:04:56, jbroman wrote:
> On 2017/03/01 at 01:19:24, haraken wrote:
> >
https://codereview.chromium.org/2726593002/diff/20001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h (right):
> > 
> >
https://codereview.chromium.org/2726593002/diff/20001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h:72: static bool
isolatedWorldsOrWorkerWorldExist() {
> > 
> > This check needs to be super fast. So it might be heavy to call acquireLoad.
> > 
> > Another idea would be:
> > 
> > - Prepare only one global variable. "bool s_isolatedWorldOrWorkerExist".
> > 
> > - Flip the boolean flag true when the main thread creates a worker thread or
an isolated world.
> > 
> > That way we can avoid using an atomic operation.
> 
> I'd be surprised if the single atomic load was sufficiently expensive. (And it
should get slightly better once we can make WTF atomics use the proper
intrinsics, probably by switching to std::atomic.) But yeah, setting the
variable on the main thread when a worker is created would solve that issue.

Okay, I've updated the CL to use a variable that's set on the main thread, PTAL.

[jbroman, 2017-03-01 20:41:07]

https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/DOMDataStore.h (right):

https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/DOMDataStore.h:156: static bool
canUseScriptWrappable() {
TBH I now find this name more confusing than helpful. I'd suggest either
inlining it, or renaming it something like "onlyMainWorldExists".

https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h (right):

https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h:120: static void
isolatedOrWorkerWorldCreated() {
nit: Why are the getter and setter so far from one another?

https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/workers/WorkerThread.cpp (right):

https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkerThread.cpp:117:
DOMWrapperWorld::isolatedOrWorkerWorldCreated();
I don't think main-thread worklets, like PaintWorklet, go through WorkerThread,
which leaves this incomplete. They do, however, go through
WorkerOrWorkletScriptController, meaning that they _do_ create a non-main world.

[adithyas, 2017-03-01 23:56:51]

https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/workers/WorkerThread.cpp (right):

https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkerThread.cpp:117:
DOMWrapperWorld::isolatedOrWorkerWorldCreated();
On 2017/03/01 at 20:41:07, jbroman wrote:
> I don't think main-thread worklets, like PaintWorklet, go through
WorkerThread, which leaves this incomplete. They do, however, go through
WorkerOrWorkletScriptController, meaning that they _do_ create a non-main world.

haraken@: jbroman@ and I discussed this offline, but what do you think of
keeping track of the number of "non main" worlds created in the main thread, and
making the canUseScriptWrappable check (for the fast path) as follows:

!WTF::internal::maybeNotMainThread() && !nonMainWorldsCreatedInMainThread

(so if we are on the main thread and the main world is the only world created on
the main thread, we can use the fast path).

[haraken, 2017-03-02 01:02:39]

On 2017/03/01 23:56:51, adithyas wrote:
>
https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/workers/WorkerThread.cpp (right):
> 
>
https://codereview.chromium.org/2726593002/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/workers/WorkerThread.cpp:117:
> DOMWrapperWorld::isolatedOrWorkerWorldCreated();
> On 2017/03/01 at 20:41:07, jbroman wrote:
> > I don't think main-thread worklets, like PaintWorklet, go through
> WorkerThread, which leaves this incomplete. They do, however, go through
> WorkerOrWorkletScriptController, meaning that they _do_ create a non-main
world.
> 
> haraken@: jbroman@ and I discussed this offline, but what do you think of
> keeping track of the number of "non main" worlds created in the main thread,
and
> making the canUseScriptWrappable check (for the fast path) as follows:
> 
> !WTF::internal::maybeNotMainThread() && !nonMainWorldsCreatedInMainThread
> 
> (so if we are on the main thread and the main world is the only world created
on
> the main thread, we can use the fast path).

Sounds nice!

[adithyas, 2017-03-03 20:58:16]

The CQ bit was checked by adithyas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-03 20:58:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-03 21:07:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-03 21:07:11]

Dry run: Try jobs failed on following builders:
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)

[adithyas, 2017-03-03 22:13:43]

Description was changed from

==========
Use isolatedWorldsOrWorkerExists() for wrapper optimization

DOMDataStore has overloaded methods (for Node*) that checks if isolated worlds
exist, and returns a main world wrapper directly if they don't exist. Node is
used because it can never be created in a worker world. This CL removes the
overloaded methods by just checking if isolated worlds or worker worlds
currently exist, and returning a main world wrapper if they both don't exist.

BUG=682322
==========

to

==========
Use mayNotBeMainThread for wrapper optimization

DOMDataStore has overloaded methods (for Node*) that checks if we're in a main
world by checking if isolated worlds exist, and returns a main world wrapper
directly if they don't exist. Node is used because it can never be created in a
worker world. 

This patch changes the main world check to checking if we're on the main thread
(using mayNotBeMainThread) and if any non-main worlds have been created on the
main thread (If there are no non-main worlds, we have to be in the main world).
This way, we don't need Node.  

BUG=682322
==========

[adithyas, 2017-03-07 19:06:22]

The CQ bit was checked by adithyas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-07 19:07:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-07 20:54:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-07 20:54:40]

Dry run: This issue passed the CQ dry run.

[adithyas, 2017-03-07 21:00:58]

I've updated the patch to use WTF::mayNotBeMainThread() to do a fast check for
if we're currently in the main world.

Note: WTF::mayNotBeMainThread() seems to always return true in asan builds,
causing the slow path to be used. Text::splitText has a DCHECK that uses
DOMDataStore::getWrapper which needs a context object to exist when using the
slow path. I've added a ScriptState::Scope (to enter and exit a context) in all
unit tests that use Text::splitText for this reason.

[jbroman, 2017-03-07 22:15:49]

jbroman@chromium.org changed reviewers:
+ yukishiino@chromium.org

[jbroman, 2017-03-07 22:15:51]

+yukishiino, who you talked to about Text::splitText

lgtm with nits

I'm not thrilled about the propagation of ScriptState::Scope into the unit
tests, but I can live with this. (Though I'm not sure the DCHECK is adding a ton
of value here since we can easily see by inspection that we're making a new
one.)

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/DOMDataStore.h (right):

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMDataStore.h:157: static bool
canUseScriptWrappable() {
nit: while here, consider renaming this something clearer (in a sense, aren't we
always "using ScriptWrappable"?). Somewhat orthogonal, but now that the argument
is gone there's even less to suggest what this means without reading the
comment.

My suggestion: something along the lines of "canUseMainWorldWrapper"
"isMainWorldFast", suggesting that we're looking for whether we are certainly in
the main world

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp (right):

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:84: unsigned
DOMWrapperWorld::numberOfNonMainWorldsCreatedInMainThread = 0;
nit: remove the word "created", since this can actually be decremented

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:192:
numberOfNonMainWorldsCreatedInMainThread--;
nit: for parallel structure, consider putting this in ~DOMWrapperWorld.
(Probably after |dispose|.)

Once there, there's an assertion that this isn't the main world, so you should
only need the isMainThread check.

[adithyas, 2017-03-07 22:58:36]

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/DOMDataStore.h (right):

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMDataStore.h:157: static bool
canUseScriptWrappable() {
On 2017/03/07 at 22:15:51, jbroman wrote:
> nit: while here, consider renaming this something clearer (in a sense, aren't
we always "using ScriptWrappable"?). Somewhat orthogonal, but now that the
argument is gone there's even less to suggest what this means without reading
the comment.
> 
> My suggestion: something along the lines of "canUseMainWorldWrapper"
"isMainWorldFast", suggesting that we're looking for whether we are certainly in
the main world

Agreed, I like "canUseMainWorldWrapper".

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp (right):

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:84: unsigned
DOMWrapperWorld::numberOfNonMainWorldsCreatedInMainThread = 0;
On 2017/03/07 at 22:15:51, jbroman wrote:
> nit: remove the word "created", since this can actually be decremented

Done.

https://codereview.chromium.org/2726593002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:192:
numberOfNonMainWorldsCreatedInMainThread--;
On 2017/03/07 at 22:15:51, jbroman wrote:
> nit: for parallel structure, consider putting this in ~DOMWrapperWorld.
(Probably after |dispose|.)
> 
> Once there, there's an assertion that this isn't the main world, so you should
only need the isMainThread check.

Fixed.

[Yuki, 2017-03-08 09:22:04]

LGTM.

Could you use V8TestingScope instead of explicitly instantiating a ScriptState?

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp (right):

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:172: if
(isMainThread())
This should be okay as long as all non-main worlds get destroyed before the main
world gets destroyed.  But I'd prefer explicitly doing this iff non-main worlds.

Especially considering worklets on main thread, it's safer, I think.

[haraken, 2017-03-08 09:25:25]

LGTM

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp (right):

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:84: unsigned
DOMWrapperWorld::numberOfNonMainWorldsInMainThread = 0;

s_numberOfNonMainWorldsInMainThread

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/RangeTest.cpp (right):

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/RangeTest.cpp:67: ScriptState::Scope
scope(scriptState);

Can we use V8TestingScope instead?

The same comment for other test files.

[adithyas, 2017-03-08 18:20:10]

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp (right):

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:84: unsigned
DOMWrapperWorld::numberOfNonMainWorldsInMainThread = 0;
On 2017/03/08 at 09:25:24, haraken wrote:
> s_numberOfNonMainWorldsInMainThread

Done

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:172: if
(isMainThread())
On 2017/03/08 at 09:22:04, Yuki(slow_til_mar08) wrote:
> This should be okay as long as all non-main worlds get destroyed before the
main world gets destroyed.  But I'd prefer explicitly doing this iff non-main
worlds.
> 
> Especially considering worklets on main thread, it's safer, I think.

There's an ASSERT(!isMainWorld()) directly before this, so this shouldn't be
executed for the main world.

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/RangeTest.cpp (right):

https://codereview.chromium.org/2726593002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/RangeTest.cpp:67: ScriptState::Scope
scope(scriptState);
On 2017/03/08 at 09:25:25, haraken wrote:
> Can we use V8TestingScope instead?
> 
> The same comment for other test files.

Yup, fixed.

[adithyas, 2017-03-08 18:20:38]

The CQ bit was checked by adithyas@chromium.org

[adithyas, 2017-03-08 18:20:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
jbroman@chromium.org, haraken@chromium.org, yukishiino@chromium.org
Link to the patchset: https://codereview.chromium.org/2726593002/#ps140001
(title: "Use V8TestingScope")

[commit-bot: I haz the power, 2017-03-08 18:21:24]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-08 20:28:47]

CQ is committing da patch.

Bot data: {"patchset_id": 140001, "attempt_start_ts": 1488997238777500,
"parent_rev": "073e1744a8b06f5d757b7fa71133f687652f1e18", "commit_rev":
"199953cd647ec50f5f07d9025e5a8ba6948f8079"}

[commit-bot: I haz the power, 2017-03-08 20:29:31]

Description was changed from

==========
Use mayNotBeMainThread for wrapper optimization

DOMDataStore has overloaded methods (for Node*) that checks if we're in a main
world by checking if isolated worlds exist, and returns a main world wrapper
directly if they don't exist. Node is used because it can never be created in a
worker world. 

This patch changes the main world check to checking if we're on the main thread
(using mayNotBeMainThread) and if any non-main worlds have been created on the
main thread (If there are no non-main worlds, we have to be in the main world).
This way, we don't need Node.  

BUG=682322
==========

to

==========
Use mayNotBeMainThread for wrapper optimization

DOMDataStore has overloaded methods (for Node*) that checks if we're in a main
world by checking if isolated worlds exist, and returns a main world wrapper
directly if they don't exist. Node is used because it can never be created in a
worker world. 

This patch changes the main world check to checking if we're on the main thread
(using mayNotBeMainThread) and if any non-main worlds have been created on the
main thread (If there are no non-main worlds, we have to be in the main world).
This way, we don't need Node.  

BUG=682322

Review-Url: https://codereview.chromium.org/2726593002
Cr-Commit-Position: refs/heads/master@{#455530}
Committed:
https://chromium.googlesource.com/chromium/src/+/199953cd647ec50f5f07d9025e5a...
==========

[commit-bot: I haz the power, 2017-03-08 20:29:32]

Committed patchset #8 (id:140001) as
https://chromium.googlesource.com/chromium/src/+/199953cd647ec50f5f07d9025e5a...

[esprehn, 2017-03-24 20:38:31]

I'm curious, does this patch mean that now all extension content scripts put all
the Node wrapper machinery into slow mode? That seems somewhat concerning. Most
users have at least one extension installed, ex. every googler as PasswordAlert.

I don't think we want to be using the non-main-world count like this since it
makes content scripts degrade the page performance (actually worse, since this
is static, so a content script in one tab can degrade perf for all other tabs in
the entire process).

[esprehn, 2017-03-24 21:46:26]

On 2017/03/24 at 20:38:31, esprehn wrote:
> I'm curious, does this patch mean that now all extension content scripts put
all the Node wrapper machinery into slow mode? That seems somewhat concerning.
Most users have at least one extension installed, ex. every googler as
PasswordAlert.
> 
> I don't think we want to be using the non-main-world count like this since it
makes content scripts degrade the page performance (actually worse, since this
is static, so a content script in one tab can degrade perf for all other tabs in
the entire process).

Oh I see we already had all this before with canUseScriptWrappable(), hmm, we
should probably think about what we might do to avoid this cliff where
installing an extension makes your bindings slower.

[haraken, 2017-03-27 04:36:20]

On 2017/03/24 21:46:26, esprehn wrote:
> On 2017/03/24 at 20:38:31, esprehn wrote:
> > I'm curious, does this patch mean that now all extension content scripts put
> all the Node wrapper machinery into slow mode? That seems somewhat concerning.
> Most users have at least one extension installed, ex. every googler as
> PasswordAlert.
> > 
> > I don't think we want to be using the non-main-world count like this since
it
> makes content scripts degrade the page performance (actually worse, since this
> is static, so a content script in one tab can degrade perf for all other tabs
in
> the entire process).
> 
> Oh I see we already had all this before with canUseScriptWrappable(), hmm, we
> should probably think about what we might do to avoid this cliff where
> installing an extension makes your bindings slower.

canUseMainWorldWrapper() is the fastest way to check if we're in the main world.
This check works only when there's no isolated world. We introduced the check
just to game Dromaeo.

holderContainsWrapper() is the second fastest way to check if we're in the main
world. I think we'll hit this path in common real-world cases.