-
mtrofin authored
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= Review-Url: https://codereview.chromium.org/2094563002 Cr-Commit-Position: refs/heads/master@{#37348}
0c7ee927