[wasm] Complete separation of compilation and instantiation

[wasm] Complete separation of compilation and instantiation

Support for serializing/deserializing the compiled wasm module.

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling
debugging scenarios. This imposes a ~20% penalty on the memory
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information
necessary to support instantiation.

Given how whatever we need to persist must be serializable, the CL
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer.

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

BUG=

Committed: https://crrev.com/0c7ee92783eaadbd62fd37f7ae1035c4778e9c7a
Cr-Commit-Position: refs/heads/master@{#37348}

[Mircea Trofin, 2016-06-23 08:19:00]

Description was changed from

==========
formatting


Imports

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

to

==========
Avoid reliance on decoded module information when instantiating a
module. We have the data at compile time. We store what's needed 
to carry on the various instantiations. 

We could re-decode the module bytes. We store them, currently, to 
enable debugging. That would be both wasteful (re-decoding), as well
as tying instantiation to debugging and the need to store a large chunk 
of contiguous memory.

The extra data is stored in FixedArrays, which are serializable.  

This change added a helper getter to FixedArray, to make retrieval
easier.

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

[Mircea Trofin, 2016-06-23 08:19:00]

mtrofin@chromium.org changed reviewers:
+ bmeurer@chromium.org, bradnelson@chromium.org

[Mircea Trofin, 2016-06-23 15:28:25]

Description was changed from

==========
Avoid reliance on decoded module information when instantiating a
module. We have the data at compile time. We store what's needed 
to carry on the various instantiations. 

We could re-decode the module bytes. We store them, currently, to 
enable debugging. That would be both wasteful (re-decoding), as well
as tying instantiation to debugging and the need to store a large chunk 
of contiguous memory.

The extra data is stored in FixedArrays, which are serializable.  

This change added a helper getter to FixedArray, to make retrieval
easier.

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

to

==========
[wasm] Further separation of compilation and instantiation 

Avoid reliance on decoded module information when instantiating a
module. We have the decoding data structure (WasmModule, etc) at 
compile time. Most of it is consumed at that time - compiling the 
wasm functions, which should form the bulk of the module. 
Compared to that, the data needed for instantiation is likely 
disproportionately small and simple - the import descriptions, the index 
of the startup function, memory and gloals size requirements, and any 
data segments (granted, these may be large).

We currently store all the wasm bytes for enabling debugging. One 
option would be to re-decode the module bytes. That would be both 
wasteful (re-decoding), and would tie unrelated use cases - debugging
and runtime. One can imagine an application opting out of debugging on
consumer devices, or debugging being implemented lazily, where we 
download the necessary information on demand - which is likely, given
the likely scenario would include large data such as symbols.

The design here copies the necessary data on the JS Heap, using data 
types that work with our serializer/deserializer - to support compiled
module storage to IndexedDB.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

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

[Mircea Trofin, 2016-06-26 01:54:43]

Patchset #10 (id:160001) has been deleted

[Mircea Trofin, 2016-06-26 01:54:52]

Patchset #9 (id:150001) has been deleted

[Mircea Trofin, 2016-06-26 01:55:02]

Patchset #8 (id:130001) has been deleted

[Mircea Trofin, 2016-06-26 02:13:08]

Description was changed from

==========
[wasm] Further separation of compilation and instantiation 

Avoid reliance on decoded module information when instantiating a
module. We have the decoding data structure (WasmModule, etc) at 
compile time. Most of it is consumed at that time - compiling the 
wasm functions, which should form the bulk of the module. 
Compared to that, the data needed for instantiation is likely 
disproportionately small and simple - the import descriptions, the index 
of the startup function, memory and gloals size requirements, and any 
data segments (granted, these may be large).

We currently store all the wasm bytes for enabling debugging. One 
option would be to re-decode the module bytes. That would be both 
wasteful (re-decoding), and would tie unrelated use cases - debugging
and runtime. One can imagine an application opting out of debugging on
consumer devices, or debugging being implemented lazily, where we 
download the necessary information on demand - which is likely, given
the likely scenario would include large data such as symbols.

The design here copies the necessary data on the JS Heap, using data 
types that work with our serializer/deserializer - to support compiled
module storage to IndexedDB.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

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

to

==========
[wasm] Further separation of compilation and instantiation 

Support for serializing/deserializing the compiled wasm module. 

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then 
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling 
debugging scenarios. This imposes a ~20% penalty on the memory 
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information 
necessary to support instantiation. 

Given how whatever we need to persist must be serializable, the CL 
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer. 

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

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

[Mircea Trofin, 2016-06-26 02:13:08]

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

[Mircea Trofin, 2016-06-26 02:13:30]

Description was changed from

==========
[wasm] Further separation of compilation and instantiation 

Support for serializing/deserializing the compiled wasm module. 

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then 
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling 
debugging scenarios. This imposes a ~20% penalty on the memory 
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information 
necessary to support instantiation. 

Given how whatever we need to persist must be serializable, the CL 
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer. 

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

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

to

==========
[wasm] Complete separation of compilation and instantiation 

Support for serializing/deserializing the compiled wasm module. 

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then 
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling 
debugging scenarios. This imposes a ~20% penalty on the memory 
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information 
necessary to support instantiation. 

Given how whatever we need to persist must be serializable, the CL 
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer. 

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

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

[Mircea Trofin, 2016-06-26 02:21:04]

PTAL.

Benedikt, is adding the proposed API to FixedArray OK? I don't need
that there, I could have it as a helper if I really want the usability, and I
only put that method there thinking it may be otherwise useful - but that
may not be the best reason. 

All: last thing to do is to implement in terms of this change the JS-facing 
Compile that Andreas (Rossberg) added recently, and then tie in the 
Chrome mechanics. My plan is to do the former once this CL here lands. 
Shouldn't be too involved, but seemed right to keep the CLs separated. 
We may need some more testing for stand-alone compile, too.

[Benedikt Meurer, 2016-06-27 03:57:13]

https://codereview.chromium.org/2094563002/diff/180001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2094563002/diff/180001/src/objects.h#newcode2651
src/objects.h:2651: Handle<T> GetValueOrNull(int index) const;
This should return a MaybeHandle. null Handles are deprecated.

[Mircea Trofin, 2016-06-27 16:54:05]

Patchset #9 (id:200001) has been deleted

[Mircea Trofin, 2016-06-27 16:59:57]

https://codereview.chromium.org/2094563002/diff/180001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2094563002/diff/180001/src/objects.h#newcode2651
src/objects.h:2651: Handle<T> GetValueOrNull(int index) const;
On 2016/06/27 03:57:13, Benedikt Meurer wrote:
> This should return a MaybeHandle. null Handles are deprecated.

Done.

[bradnelson, 2016-06-27 22:28:47]

lgtm
The insides and outsides bleed together, but that was true before.

https://codereview.chromium.org/2094563002/diff/220001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/2094563002/diff/220001/src/objects.h#newcode2651
src/objects.h:2651: MaybeHandle<T> GetValueOrNull(int index) const;
Optional. I've noticed a few other places these might be named more like:
MaybeHandle<T> GetValue(int index) const;
Handle<T> GetValueChecked(int index) const;

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.cc
File src/wasm/wasm-module.cc (right):

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.c...
src/wasm/wasm-module.cc:129: enum CompiledWasmObjectFields {
This all seems structurally complicated enough I wonder if a comment diagramming
the resulting structure would be useful for reference?

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.c...
src/wasm/wasm-module.cc:145: enum WasmImportDataFields {
Isn't this more like module meta-data?

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.c...
src/wasm/wasm-module.cc:173: CHECK_LE(dest_addr + source_size, mem_size);
On the theme of overflow, this can wrap around.
Maybe:
CHECK_LE(dest_addr, mem_size - source_size);

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.c...
src/wasm/wasm-module.cc:1041: if (thrower.error()) break;
Why here?, Probably better to bubble out after the site that can fail?

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.c...
src/wasm/wasm-module.cc:1069: // TODO(wasm): saving the module bytes for
debugging is wasteful. We should
saving -> Saving

[Mircea Trofin, 2016-06-28 05:24:21]

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.cc
File src/wasm/wasm-module.cc (right):

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.c...
src/wasm/wasm-module.cc:129: enum CompiledWasmObjectFields {
On 2016/06/27 22:28:47, bradnelson wrote:
> This all seems structurally complicated enough I wonder if a comment
diagramming
> the resulting structure would be useful for reference?

Done.

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.c...
src/wasm/wasm-module.cc:145: enum WasmImportDataFields {
On 2016/06/27 22:28:47, bradnelson wrote:
> Isn't this more like module meta-data?

Done.

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.c...
src/wasm/wasm-module.cc:173: CHECK_LE(dest_addr + source_size, mem_size);
On 2016/06/27 22:28:47, bradnelson wrote:
> On the theme of overflow, this can wrap around.
> Maybe:
> CHECK_LE(dest_addr, mem_size - source_size);

Done.

https://codereview.chromium.org/2094563002/diff/220001/src/wasm/wasm-module.c...
src/wasm/wasm-module.cc:1041: if (thrower.error()) break;
On 2016/06/27 22:28:47, bradnelson wrote:
> Why here?, Probably better to bubble out after the site that can fail?

That's where it was done before. I agree, it's strange. Fixed. Also, no point in
breaking, when we can just return.

[Mircea Trofin, 2016-06-28 05:24:30]

The CQ bit was checked by mtrofin@chromium.org

[Mircea Trofin, 2016-06-28 05:24:30]

The patchset sent to the CQ was uploaded after l-g-t-m from
bradnelson@chromium.org
Link to the patchset: https://codereview.chromium.org/2094563002/#ps260001
(title: "Incorporated Feedback")

[commit-bot: I haz the power, 2016-06-28 05:24:40]

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, 2016-06-28 05:29:12]

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

[commit-bot: I haz the power, 2016-06-28 05:29:12]

Try jobs failed on following builders:
  v8_presubmit on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/18160)

[Mircea Trofin, 2016-06-28 20:44:26]

The CQ bit was checked by mtrofin@chromium.org

[commit-bot: I haz the power, 2016-06-28 20:44:37]

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, 2016-06-28 20:46:43]

Description was changed from

==========
[wasm] Complete separation of compilation and instantiation 

Support for serializing/deserializing the compiled wasm module. 

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then 
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling 
debugging scenarios. This imposes a ~20% penalty on the memory 
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information 
necessary to support instantiation. 

Given how whatever we need to persist must be serializable, the CL 
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer. 

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

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

to

==========
[wasm] Complete separation of compilation and instantiation 

Support for serializing/deserializing the compiled wasm module. 

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then 
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling 
debugging scenarios. This imposes a ~20% penalty on the memory 
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information 
necessary to support instantiation. 

Given how whatever we need to persist must be serializable, the CL 
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer. 

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

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

[commit-bot: I haz the power, 2016-06-28 20:46:44]

Committed patchset #11 (id:260001)

[commit-bot: I haz the power, 2016-06-28 20:49:37]

Description was changed from

==========
[wasm] Complete separation of compilation and instantiation 

Support for serializing/deserializing the compiled wasm module. 

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then 
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling 
debugging scenarios. This imposes a ~20% penalty on the memory 
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information 
necessary to support instantiation. 

Given how whatever we need to persist must be serializable, the CL 
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer. 

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

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

to

==========
[wasm] Complete separation of compilation and instantiation

Support for serializing/deserializing the compiled wasm module.

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling
debugging scenarios. This imposes a ~20% penalty on the memory
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information
necessary to support instantiation.

Given how whatever we need to persist must be serializable, the CL
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer.

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

BUG=

Committed: https://crrev.com/0c7ee92783eaadbd62fd37f7ae1035c4778e9c7a
Cr-Commit-Position: refs/heads/master@{#37348}
==========

[commit-bot: I haz the power, 2016-06-28 20:49:38]

Patchset 11 (id:??) landed as
https://crrev.com/0c7ee92783eaadbd62fd37f7ae1035c4778e9c7a
Cr-Commit-Position: refs/heads/master@{#37348}