Bindings: Separate WorldIdConstants into WorldTypes and WorldId

Bindings: Separate WorldIdConstants to WorldTypes and WorldId

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldId. This encapsulates identifier allocation logic in
DOMWrapperWorld[1] and makes it easier to expand the identifier space for
Worklets[2].

[1] WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.
[2] https://codereview.chromium.org/2735823006/

BUG=697622, 697629
Review-Url: https://codereview.chromium.org/2735973006
Cr-Commit-Position: refs/heads/master@{#455700}
Committed: https://chromium.googlesource.com/chromium/src/+/611dfce737a7df5d5a1e88e8528d405ebed37b8d

[nhiroki, 2017-03-08 07:56:11]

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

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

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-08 08:14:26]

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

[commit-bot: I haz the power, 2017-03-08 08:14:27]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  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-...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[nhiroki, 2017-03-08 08:28:09]

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

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

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

[nhiroki, 2017-03-08 09:22:22]

Description was changed from

==========
Bindings: Separate WorldIdConstants into WorldTypes and WorldIds

BUG=
==========

to

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldIds

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldIds. This encapsulates identifier allocation logic in
DOMWrapperWorld(*) and makes it easier to expand the identifier space for
Worklets (see the issues).

(*) WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.

BUG=697622, 697629
==========

[nhiroki, 2017-03-08 09:22:58]

Description was changed from

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldIds

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldIds. This encapsulates identifier allocation logic in
DOMWrapperWorld(*) and makes it easier to expand the identifier space for
Worklets (see the issues).

(*) WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.

BUG=697622, 697629
==========

to

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldIdSpace

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldIdSpace. This encapsulates identifier allocation logic in
DOMWrapperWorld(*) and makes it easier to expand the identifier space for
Worklets (see the issues).

(*) WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.

BUG=697622, 697629
==========

[nhiroki, 2017-03-08 09:24:28]

Description was changed from

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldIdSpace

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldIdSpace. This encapsulates identifier allocation logic in
DOMWrapperWorld(*) and makes it easier to expand the identifier space for
Worklets (see the issues).

(*) WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.

BUG=697622, 697629
==========

to

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldIdSpace

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldIdSpace. This encapsulates identifier allocation logic in
DOMWrapperWorld[1] and makes it easier to expand the identifier space for
Worklets [2].

[1] WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.
[2] https://codereview.chromium.org/2735823006/

BUG=697622, 697629
==========

[nhiroki, 2017-03-08 09:25:23]

Patchset #1 (id:1) has been deleted

[nhiroki, 2017-03-08 09:25:33]

Patchset #1 (id:20001) has been deleted

[nhiroki, 2017-03-08 09:25:43]

Patchset #1 (id:40001) has been deleted

[nhiroki, 2017-03-08 09:25:50]

Patchset #1 (id:60001) has been deleted

[nhiroki, 2017-03-08 09:25:57]

Patchset #1 (id:80001) has been deleted

[nhiroki, 2017-03-08 09:30:05]

nhiroki@chromium.org changed reviewers:
+ haraken@chromium.org, peria@chromium.org, yukishiino@chromium.org

[nhiroki, 2017-03-08 09:30:06]

Hi, can you take a look at this? Thanks!

[nhiroki, 2017-03-08 09:30:46]

Description was changed from

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldIdSpace

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldIdSpace. This encapsulates identifier allocation logic in
DOMWrapperWorld[1] and makes it easier to expand the identifier space for
Worklets [2].

[1] WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.
[2] https://codereview.chromium.org/2735823006/

BUG=697622, 697629
==========

to

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldIdSpace

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldIdSpace. This encapsulates identifier allocation logic in
DOMWrapperWorld[1] and makes it easier to expand the identifier space for
Worklets[2].

[1] WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.
[2] https://codereview.chromium.org/2735823006/

BUG=697622, 697629
==========

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

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

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:58: NOTREACHED();

Why is it not reached?

[peria, 2017-03-08 09:48:19]

LGTM % nits

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

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:60: // Currently,
WorldId for a worker/worklet is fixed value, but this doesn't
*a* fixed value

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:141: if (worldId
== MainWorldId)
isMainWorld()

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

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h:49: enum
WorldIdSpace {
Can you move this enum into DOMWrapperWorld class?
And I prefer 'WorldId' for its type name.

[commit-bot: I haz the power, 2017-03-08 10:03:23]

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

[commit-bot: I haz the power, 2017-03-08 10:03:26]

Dry run: This issue passed the CQ dry run.

[nhiroki, 2017-03-08 10:23:36]

Description was changed from

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldIdSpace

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldIdSpace. This encapsulates identifier allocation logic in
DOMWrapperWorld[1] and makes it easier to expand the identifier space for
Worklets[2].

[1] WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.
[2] https://codereview.chromium.org/2735823006/

BUG=697622, 697629
==========

to

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldId

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldId. This encapsulates identifier allocation logic in
DOMWrapperWorld[1] and makes it easier to expand the identifier space for
Worklets[2].

[1] WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.
[2] https://codereview.chromium.org/2735823006/

BUG=697622, 697629
==========

[nhiroki, 2017-03-08 10:23:51]

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

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

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

[nhiroki, 2017-03-08 10:24:53]

Thank you! Updated.

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

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:58: NOTREACHED();
On 2017/03/08 09:39:09, haraken wrote:
> 
> Why is it not reached?

Because IsolatedWorld is created by DOMWrapperWorld::ensureIsolatedWorld that
doesn't call this function.

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:60: // Currently,
WorldId for a worker/worklet is fixed value, but this doesn't
On 2017/03/08 09:48:19, peria wrote:
> *a* fixed value

Done.

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:141: if (worldId
== MainWorldId)
On 2017/03/08 09:48:19, peria wrote:
> isMainWorld()

isMainWorld() is not available here because fromWorldId() is a static method.

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

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h:49: enum
WorldIdSpace {
On 2017/03/08 09:48:19, peria wrote:
> Can you move this enum into DOMWrapperWorld class?
> And I prefer 'WorldId' for its type name.

Done.

[haraken, 2017-03-08 10:27:47]

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

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:58: NOTREACHED();
On 2017/03/08 10:24:52, nhiroki (slow) wrote:
> On 2017/03/08 09:39:09, haraken wrote:
> > 
> > Why is it not reached?
> 
> Because IsolatedWorld is created by DOMWrapperWorld::ensureIsolatedWorld that
> doesn't call this function.

Hmm. So an ID for an isolated world is provided externally. Then who provides an
ID for a worker/worklet world?

We need to somehow make sure that there's no conflict in the IDs.

[nhiroki, 2017-03-08 10:44:23]

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

https://codereview.chromium.org/2735973006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:58: NOTREACHED();
On 2017/03/08 10:27:47, haraken wrote:
> On 2017/03/08 10:24:52, nhiroki (slow) wrote:
> > On 2017/03/08 09:39:09, haraken wrote:
> > > 
> > > Why is it not reached?
> > 
> > Because IsolatedWorld is created by DOMWrapperWorld::ensureIsolatedWorld
that
> > doesn't call this function.
> 
> Hmm. So an ID for an isolated world is provided externally.

That's right.

> Then who provides an ID for a worker/worklet world?

I'll make a dynamic allocation mechanism for a worker/worklet world in
https://codereview.chromium.org/2735823006/ (not updated yet). It will pick up
an ID from the unused range [WorkerWorldId, INT_MAX) and getWorldIdForType()
calls it, so it never conflict with others. (Probably getWorldIdForType will be
renamed to generateWorldIdForType or something at the time)

> We need to somehow make sure that there's no conflict in the IDs.

[haraken, 2017-03-08 10:48:56]

LGTM

[commit-bot: I haz the power, 2017-03-08 12:36:48]

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

[commit-bot: I haz the power, 2017-03-08 12:36:49]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Yuki, 2017-03-08 14:07:51]

Looks good in general.

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

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:323: int
DOMWrapperWorld::getWorldIdForType(WorldType worldType) {
IIUC, this function is going to be used to get an identifier for a **new** world
being created, right?  This function should return a different ID for every call
(on the same thread).

If so, "get"WorldIdForType sounds weird to me because "get" implies that it
returns an existing one.  I'd prefer newWorldIdForType.

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:326: return
UnknownWorldId;
I think "Unknown" is not a good name.

It seems that use cases are
  V8GCController::collectGarbage
  V8PerIsolateData::ensureScriptRegexpContext
  DataConsumerHandleTestUtil::Thread::initialize

Then, I'd like to give types for each one.
For example,
  GarbageCollector
  RegExp
  Testing  // Ideally, I'd like to deprecate this one.

Otherwise, I'd like to assign an unique ID for each at least, like
DocumentXMLTreeViewerWorldId.

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:330:
NOTREACHED();
Could you add a comment about the reason why we don't hit this?

I've already read your reply, but I'd like to have it as a comment here.

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h (right):

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h:51: // WorldIdSpace
above).
nit: Could you update the comment?
Not WorldIdSpace, not above.

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/xml/DocumentXMLTreeViewer.cpp (right):

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/xml/DocumentXMLTreeViewer.cpp:27:
DOMWrapperWorld::DocumentXMLTreeViewerWorldId, sources, nullptr);
Should DocumentXMLTreeViewerWorldId be also a new type?

[nhiroki, 2017-03-09 03:39:21]

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

[commit-bot: I haz the power, 2017-03-09 03:39:45]

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

[nhiroki, 2017-03-09 03:40:29]

Thank you! Updated.

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

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:323: int
DOMWrapperWorld::getWorldIdForType(WorldType worldType) {
On 2017/03/08 14:07:51, Yuki(slow_til_mar08) wrote:
> IIUC, this function is going to be used to get an identifier for a **new**
world
> being created, right?  This function should return a different ID for every
call
> (on the same thread).
> 
> If so, "get"WorldIdForType sounds weird to me because "get" implies that it
> returns an existing one.  I'd prefer newWorldIdForType.

I'd prefer to rename this in my second patch that makes this return a different
id every time because in this patch this function always returns an existing id
for a type.

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:326: return
UnknownWorldId;
On 2017/03/08 14:07:51, Yuki(slow_til_mar08) wrote:
> I think "Unknown" is not a good name.
> 
> It seems that use cases are
>   V8GCController::collectGarbage
>   V8PerIsolateData::ensureScriptRegexpContext
>   DataConsumerHandleTestUtil::Thread::initialize
> 
> Then, I'd like to give types for each one.
> For example,
>   GarbageCollector
>   RegExp
>   Testing  // Ideally, I'd like to deprecate this one.
> 
> Otherwise, I'd like to assign an unique ID for each at least, like
> DocumentXMLTreeViewerWorldId.

Done.

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp:330:
NOTREACHED();
On 2017/03/08 14:07:51, Yuki(slow_til_mar08) wrote:
> Could you add a comment about the reason why we don't hit this?
> 
> I've already read your reply, but I'd like to have it as a comment here.

Done.

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h (right):

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h:51: // WorldIdSpace
above).
On 2017/03/08 14:07:51, Yuki(slow_til_mar08) wrote:
> nit: Could you update the comment?
> Not WorldIdSpace, not above.

Done.

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/xml/DocumentXMLTreeViewer.cpp (right):

https://codereview.chromium.org/2735973006/diff/110001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/xml/DocumentXMLTreeViewer.cpp:27:
DOMWrapperWorld::DocumentXMLTreeViewerWorldId, sources, nullptr);
On 2017/03/08 14:07:51, Yuki(slow_til_mar08) wrote:
> Should DocumentXMLTreeViewerWorldId be also a new type?

This is a part of IsolatedWorlds and doesn't need to have a unique world type, I
think.

[commit-bot: I haz the power, 2017-03-09 04:19:37]

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

[commit-bot: I haz the power, 2017-03-09 04:19:38]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Yuki, 2017-03-09 07:32:46]

LGTM.

[nhiroki, 2017-03-09 07:46:25]

The CQ bit was checked by nhiroki@chromium.org

[nhiroki, 2017-03-09 07:46:26]

The patchset sent to the CQ was uploaded after l-g-t-m from peria@chromium.org,
haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/2735973006/#ps150001
(title: "rebase")

[commit-bot: I haz the power, 2017-03-09 07:46:41]

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-09 08:44:59]

CQ is committing da patch.

Bot data: {"patchset_id": 150001, "attempt_start_ts": 1489045585771670,
"parent_rev": "5e556038ac16e5447b8a89daa293d3d2c4f3a288", "commit_rev":
"611dfce737a7df5d5a1e88e8528d405ebed37b8d"}

[commit-bot: I haz the power, 2017-03-09 08:45:43]

Description was changed from

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldId

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldId. This encapsulates identifier allocation logic in
DOMWrapperWorld[1] and makes it easier to expand the identifier space for
Worklets[2].

[1] WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.
[2] https://codereview.chromium.org/2735823006/

BUG=697622, 697629
==========

to

==========
Bindings: Separate WorldIdConstants to WorldTypes and WorldId

This is a clean-up CL and doesn't change behavior.

For improving extensibility, this CL separates WorldIdConstants to 2 parts:
WorldTypes and WorldId. This encapsulates identifier allocation logic in
DOMWrapperWorld[1] and makes it easier to expand the identifier space for
Worklets[2].

[1] WorldIds for IsolatedWorlds still need to be given from out of
    DOMWrapperWorld because of its unique convention to allocate the identifier.
[2] https://codereview.chromium.org/2735823006/

BUG=697622, 697629

Review-Url: https://codereview.chromium.org/2735973006
Cr-Commit-Position: refs/heads/master@{#455700}
Committed:
https://chromium.googlesource.com/chromium/src/+/611dfce737a7df5d5a1e88e8528d...
==========

[commit-bot: I haz the power, 2017-03-09 08:45:45]

Committed patchset #4 (id:150001) as
https://chromium.googlesource.com/chromium/src/+/611dfce737a7df5d5a1e88e8528d...