[wasm] Introduce instance types for WebAssembly.* objects.

[wasm] Introduce instance types for WebAssembly.* objects.

This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).

In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.

BUG=v8:6547
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

Review-Url: https://codereview.chromium.org/2964943002
Cr-Commit-Position: refs/heads/master@{#46475}
Committed: https://chromium.googlesource.com/v8/v8/+/17001a05c8ca848b75f3c667192bcf99bdcd42fd

[titzer, 2017-07-04 11:54:12]

Description was changed from

==========
[wasm] Introduce instance types for WebAssembly.* objects.

This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).

In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.

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

to

==========
[wasm] Introduce instance types for WebAssembly.* objects.

This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).

In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
==========

[titzer, 2017-07-04 11:55:46]

Description was changed from

==========
[wasm] Introduce instance types for WebAssembly.* objects.

This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).

In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
==========

to

==========
[wasm] Introduce instance types for WebAssembly.* objects.

This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).

In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.

BUG=v8:6547
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
==========

[titzer, 2017-07-04 11:56:00]

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

[commit-bot: I haz the power, 2017-07-04 11:56:04]

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-07-04 12:01:14]

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

[commit-bot: I haz the power, 2017-07-04 12:01:14]

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

[titzer, 2017-07-04 12:31:52]

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

[commit-bot: I haz the power, 2017-07-04 12:31:54]

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-07-04 12:36:44]

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

[commit-bot: I haz the power, 2017-07-04 12:36:45]

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

[titzer, 2017-07-04 12:39:22]

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

[commit-bot: I haz the power, 2017-07-04 12:39:24]

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-07-04 13:06:56]

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

[commit-bot: I haz the power, 2017-07-04 13:06:56]

Dry run: Try jobs failed on following builders:
  v8_linux_dbg_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/28558)
  v8_linux_dbg_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng_triggered/b...)

[titzer, 2017-07-04 14:54:00]

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

[commit-bot: I haz the power, 2017-07-04 14:54:05]

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-07-04 15:22:14]

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

[commit-bot: I haz the power, 2017-07-04 15:22:15]

Dry run: Try jobs failed on following builders:
  v8_linux64_asan_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng/buil...)
  v8_linux64_asan_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng_trig...)

[Igor Sheludko, 2017-07-05 09:56:33]

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

[Igor Sheludko, 2017-07-05 09:56:35]

I like the new approach.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.cc
File src/wasm/wasm-objects.cc (right):

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.c...
src/wasm/wasm-objects.cc:19: #include "src/objects/object-macros.h"
Same here (comment and object-macros-undef.h).

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h
File src/wasm/wasm-objects.h (right):

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:19: #include "src/objects/object-macros.h"
This include is usually added with a comment:
  // Has to be the last include (doesn't have include guards):
and with
  #include "src/objects/object-macros-undef.h"
at the end of file.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:55: kCompiledModuleIndex,
Given that these fields are no longer embedder fields but a part of object
header I'd suggest to define their offsets but not their indices.

Also, consider using DEFINE_FIELD_OFFSET_CONSTANTS macro.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:76: kFunctionsIndex,
Same here.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:108: kArrayBufferIndex,
Same here.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:144: kCompiledModuleIndex,
Same here.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:184: kInstanceIndex,
Same here.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:199: DECL_OOL_QUERY(WasmSharedModuleData)
I'd suggest you to be even more intrusive and introduce another instance type
for this and inherit from Struct. This should simplify things.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:209: kModuleWrapperIndex,
Same here, once you turn it to Struct.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:268: class WasmCompiledModule : public FixedArray {
Struct?

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:271: kFieldCount
Same here.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:559: class WasmDebugInfo : public FixedArray {
Struct?

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:565: kInstanceIndex,
Same here.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:636: class WasmInstanceWrapper : public FixedArray {
Struct?

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:639: kWrapperInstanceObjectIndex,
Same here.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:701: #define ARR_OFF(x) (FixedArray::kHeaderSize +
((x)*kPointerSize))
These two macros should not be necessary once you switch to kXXXOffset approach.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:776: #undef DECL_OOL_CAST
DECL_OOL_* macros should not be necessary once you switch define respective
classes as Structs instead of FixedArrays.

[titzer, 2017-07-06 12:16:17]

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

[commit-bot: I haz the power, 2017-07-06 12:16:31]

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-07-06 13:02:02]

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

[commit-bot: I haz the power, 2017-07-06 13:02:03]

Dry run: Try jobs failed on following builders:
  v8_linux64_asan_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng/buil...)
  v8_linux64_asan_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng_trig...)

[titzer, 2017-07-06 14:10:30]

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.cc
File src/wasm/wasm-objects.cc (right):

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.c...
src/wasm/wasm-objects.cc:19: #include "src/objects/object-macros.h"
On 2017/07/05 09:56:33, Igor Sheludko wrote:
> Same here (comment and object-macros-undef.h).

Done.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h
File src/wasm/wasm-objects.h (right):

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:19: #include "src/objects/object-macros.h"
On 2017/07/05 09:56:34, Igor Sheludko wrote:
> This include is usually added with a comment:
>   // Has to be the last include (doesn't have include guards):
> and with
>   #include "src/objects/object-macros-undef.h"
> at the end of file.

Done.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:55: kCompiledModuleIndex,
On 2017/07/05 09:56:34, Igor Sheludko wrote:
> Given that these fields are no longer embedder fields but a part of object
> header I'd suggest to define their offsets but not their indices.
> 
> Also, consider using DEFINE_FIELD_OFFSET_CONSTANTS macro.

Done. They are now defined one-by-one with a new macro.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:199: DECL_OOL_QUERY(WasmSharedModuleData)
On 2017/07/05 09:56:34, Igor Sheludko wrote:
> I'd suggest you to be even more intrusive and introduce another instance type
> for this and inherit from Struct. This should simplify things.

As per offline discussion, I think this makes sense and can do this in a
follow-up CL.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:701: #define ARR_OFF(x) (FixedArray::kHeaderSize +
((x)*kPointerSize))
On 2017/07/05 09:56:34, Igor Sheludko wrote:
> These two macros should not be necessary once you switch to kXXXOffset
approach.

Done.

https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
src/wasm/wasm-objects.h:776: #undef DECL_OOL_CAST
On 2017/07/05 09:56:34, Igor Sheludko wrote:
> DECL_OOL_* macros should not be necessary once you switch define respective
> classes as Structs instead of FixedArrays.

Yeah, I'd like to change these all to be closer to the ones in objects.h (and
pull out wasm-objects-inl.h) in the next CL.

[titzer, 2017-07-06 14:26:02]

titzer@chromium.org changed reviewers:
+ clemensh@chromium.org, mtrofin@chromium.org, ulan@chromium.org

[titzer, 2017-07-06 14:26:19]

PTAL

On 2017/07/06 14:10:30, titzer wrote:
> https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.cc
> File src/wasm/wasm-objects.cc (right):
> 
>
https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.c...
> src/wasm/wasm-objects.cc:19: #include "src/objects/object-macros.h"
> On 2017/07/05 09:56:33, Igor Sheludko wrote:
> > Same here (comment and object-macros-undef.h).
> 
> Done.
> 
> https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h
> File src/wasm/wasm-objects.h (right):
> 
>
https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
> src/wasm/wasm-objects.h:19: #include "src/objects/object-macros.h"
> On 2017/07/05 09:56:34, Igor Sheludko wrote:
> > This include is usually added with a comment:
> >   // Has to be the last include (doesn't have include guards):
> > and with
> >   #include "src/objects/object-macros-undef.h"
> > at the end of file.
> 
> Done.
> 
>
https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
> src/wasm/wasm-objects.h:55: kCompiledModuleIndex,
> On 2017/07/05 09:56:34, Igor Sheludko wrote:
> > Given that these fields are no longer embedder fields but a part of object
> > header I'd suggest to define their offsets but not their indices.
> > 
> > Also, consider using DEFINE_FIELD_OFFSET_CONSTANTS macro.
> 
> Done. They are now defined one-by-one with a new macro.
> 
>
https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
> src/wasm/wasm-objects.h:199: DECL_OOL_QUERY(WasmSharedModuleData)
> On 2017/07/05 09:56:34, Igor Sheludko wrote:
> > I'd suggest you to be even more intrusive and introduce another instance
type
> > for this and inherit from Struct. This should simplify things.
> 
> As per offline discussion, I think this makes sense and can do this in a
> follow-up CL.
> 
>
https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
> src/wasm/wasm-objects.h:701: #define ARR_OFF(x) (FixedArray::kHeaderSize +
> ((x)*kPointerSize))
> On 2017/07/05 09:56:34, Igor Sheludko wrote:
> > These two macros should not be necessary once you switch to kXXXOffset
> approach.
> 
> Done.
> 
>
https://codereview.chromium.org/2964943002/diff/40001/src/wasm/wasm-objects.h...
> src/wasm/wasm-objects.h:776: #undef DECL_OOL_CAST
> On 2017/07/05 09:56:34, Igor Sheludko wrote:
> > DECL_OOL_* macros should not be necessary once you switch define respective
> > classes as Structs instead of FixedArrays.
> 
> Yeah, I'd like to change these all to be closer to the ones in objects.h (and
> pull out wasm-objects-inl.h) in the next CL.

[Igor Sheludko, 2017-07-06 14:34:19]

lgtm

[titzer, 2017-07-06 15:26:07]

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

[commit-bot: I haz the power, 2017-07-06 15:26:17]

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-07-06 16:37:26]

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

[commit-bot: I haz the power, 2017-07-06 16:37:27]

Dry run: This issue passed the CQ dry run.

[ulan, 2017-07-07 08:31:10]

lgtm

[titzer, 2017-07-07 09:02:59]

titzer@chromium.org changed reviewers:
+ rossberg@chromium.org

[rossberg, 2017-07-07 09:33:22]

LGTM with comments

https://codereview.chromium.org/2964943002/diff/100001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2964943002/diff/100001/src/objects.h#newcode76
src/objects.h:76: //         - WebAssemblyInstance
These names don't seem to match the actual classes.

https://codereview.chromium.org/2964943002/diff/100001/src/runtime/runtime-te...
File src/runtime/runtime-test.cc (right):

https://codereview.chromium.org/2964943002/diff/100001/src/runtime/runtime-te...
src/runtime/runtime-test.cc:967: CONVERT_ARG_HANDLE_CHECKED(JSObject,
instance_obj, 0);
Why not WasmInstanceObject here instead of the separate cast below?

https://codereview.chromium.org/2964943002/diff/100001/src/runtime/runtime-te...
src/runtime/runtime-test.cc:978: CONVERT_ARG_HANDLE_CHECKED(JSObject,
instance_obj, 0);
Same here.

https://codereview.chromium.org/2964943002/diff/100001/src/value-serializer.cc
File src/value-serializer.cc (right):

https://codereview.chromium.org/2964943002/diff/100001/src/value-serializer.c...
src/value-serializer.cc:823: Utils::ToLocal(Handle<JSObject>::cast(object))));
Why is this cast necessary? Shouldn't the type mapping be adjusted for ToLocal
instead?

https://codereview.chromium.org/2964943002/diff/100001/src/wasm/wasm-objects.h
File src/wasm/wasm-objects.h (right):

https://codereview.chromium.org/2964943002/diff/100001/src/wasm/wasm-objects....
src/wasm/wasm-objects.h:34: #define DECL_OOL_QUERY(type) static bool
Is##type(Object* object);
What does OOL stand for? Maybe "STATIC" would be clearer, or leave it out
entirely?

https://codereview.chromium.org/2964943002/diff/100001/src/wasm/wasm-objects....
src/wasm/wasm-objects.h:220: class WasmSharedModuleData : public FixedArray {
If you start introducing custom instance types for Wasm, why not turn this and
other FixedArrays into structs while you're at it?

[titzer, 2017-07-07 11:32:49]

https://codereview.chromium.org/2964943002/diff/100001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2964943002/diff/100001/src/objects.h#newcode76
src/objects.h:76: //         - WebAssemblyInstance
On 2017/07/07 09:33:21, rossberg wrote:
> These names don't seem to match the actual classes.

Done.

https://codereview.chromium.org/2964943002/diff/100001/src/runtime/runtime-te...
File src/runtime/runtime-test.cc (right):

https://codereview.chromium.org/2964943002/diff/100001/src/runtime/runtime-te...
src/runtime/runtime-test.cc:967: CONVERT_ARG_HANDLE_CHECKED(JSObject,
instance_obj, 0);
On 2017/07/07 09:33:21, rossberg wrote:
> Why not WasmInstanceObject here instead of the separate cast below?

Done.

https://codereview.chromium.org/2964943002/diff/100001/src/runtime/runtime-te...
src/runtime/runtime-test.cc:978: CONVERT_ARG_HANDLE_CHECKED(JSObject,
instance_obj, 0);
On 2017/07/07 09:33:21, rossberg wrote:
> Same here.

Done.

https://codereview.chromium.org/2964943002/diff/100001/src/value-serializer.cc
File src/value-serializer.cc (right):

https://codereview.chromium.org/2964943002/diff/100001/src/value-serializer.c...
src/value-serializer.cc:823: Utils::ToLocal(Handle<JSObject>::cast(object))));
On 2017/07/07 09:33:22, rossberg wrote:
> Why is this cast necessary? Shouldn't the type mapping be adjusted for ToLocal
> instead?

There is no overload for WasmModuleObject. I added a TODO.

https://codereview.chromium.org/2964943002/diff/100001/src/wasm/wasm-objects.h
File src/wasm/wasm-objects.h (right):

https://codereview.chromium.org/2964943002/diff/100001/src/wasm/wasm-objects....
src/wasm/wasm-objects.h:34: #define DECL_OOL_QUERY(type) static bool
Is##type(Object* object);
On 2017/07/07 09:33:22, rossberg wrote:
> What does OOL stand for? Maybe "STATIC" would be clearer, or leave it out
> entirely?

OOL is out-of-line.

The reason for these is that they are defined in the .cc file, although I plan
to move everything to a -inl.h file.

https://codereview.chromium.org/2964943002/diff/100001/src/wasm/wasm-objects....
src/wasm/wasm-objects.h:220: class WasmSharedModuleData : public FixedArray {
On 2017/07/07 09:33:22, rossberg wrote:
> If you start introducing custom instance types for Wasm, why not turn this and
> other FixedArrays into structs while you're at it?

As discussed with ishell@, that's a next step.

[titzer, 2017-07-07 11:40:59]

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

[commit-bot: I haz the power, 2017-07-07 11:41:10]

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-07-07 12:24:18]

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

[commit-bot: I haz the power, 2017-07-07 12:24:19]

Dry run: This issue passed the CQ dry run.

[titzer, 2017-07-07 12:25:59]

The CQ bit was checked by titzer@chromium.org

[titzer, 2017-07-07 12:25:59]

The patchset sent to the CQ was uploaded after l-g-t-m from ishell@chromium.org,
rossberg@chromium.org, ulan@chromium.org
Link to the patchset: https://codereview.chromium.org/2964943002/#ps120001
(title: "Address rossberg comments.")

[commit-bot: I haz the power, 2017-07-07 12:26:08]

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-07-07 12:27:57]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1499430359015820,
"parent_rev": "c16a39f23e13a2135f43f749f0dea37b9f045097", "commit_rev":
"17001a05c8ca848b75f3c667192bcf99bdcd42fd"}

[commit-bot: I haz the power, 2017-07-07 12:28:10]

Description was changed from

==========
[wasm] Introduce instance types for WebAssembly.* objects.

This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).

In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.

BUG=v8:6547
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
==========

to

==========
[wasm] Introduce instance types for WebAssembly.* objects.

This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).

In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.

BUG=v8:6547
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

Review-Url: https://codereview.chromium.org/2964943002
Cr-Commit-Position: refs/heads/master@{#46475}
Committed:
https://chromium.googlesource.com/v8/v8/+/17001a05c8ca848b75f3c667192bcf99bdc...
==========

[commit-bot: I haz the power, 2017-07-07 12:28:12]

Committed patchset #7 (id:120001) as
https://chromium.googlesource.com/v8/v8/+/17001a05c8ca848b75f3c667192bcf99bdc...

[ahaas, 2017-07-10 10:48:20]

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

[ahaas, 2017-07-10 10:48:22]

https://codereview.chromium.org/2964943002/diff/40001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2964943002/diff/40001/src/objects.h#newcode76
src/objects.h:76: //         - WebAssemblyInstance
I think this should be WasmInstance, for consistency.

https://codereview.chromium.org/2964943002/diff/100001/src/wasm/wasm-objects.h
File src/wasm/wasm-objects.h (right):

https://codereview.chromium.org/2964943002/diff/100001/src/wasm/wasm-objects....
src/wasm/wasm-objects.h:92: DEF_OFFSET(Functions)
Could you interleave the DEF_OFFSET lines with the DECL_ACCESSORS lines above? I
think it easier to have the same order for both of them.