For real streaming compilation (bug 1347644), I think we want to buffer up enough bytes to decode the module environment before starting a compilation helper task to do a streaming decode of the code section. To do a streaming decode, we want to know the code section size so that the memory can be allocated and not need to be resized during parallel compilation. This implies having DecodeModuleEnvironment() startSection(SectionId::Code). The patches end up simplifying the code too.

The next patch ended up suggesting a refactoring I should've made to begin with: putting (sectionStart, sectionSize) into a Maybe<Pair> that is returned as an outparam in startSection() and given to finishSection().

This patch does what comment 0 said, sticking a MaybeSectionRange in the ModuleEnvironment which ends up obviating the need for peekSectionSize().

Comment on attachment 8915115 [details] [diff] [review] tidy-start-section Review of attachment 8915115 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/wasm/WasmValidate.h @@ +25,5 @@ > namespace js { > namespace wasm { > > +// This struct captures the bytecode offset of a section's payload (so not > +// including the header) and the section size of the payload. This should probably be just "the size of that payload".

Comment on attachment 8915116 [details] [diff] [review] start-code-section-in-decode-module-env Review of attachment 8915116 [details] [diff] [review]: ----------------------------------------------------------------- Nice.

Pushed by lwagner@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/62fc2f51d566 Baldr: stidy Decoder::startSection (r=lth) https://hg.mozilla.org/integration/mozilla-inbound/rev/13b556ec5a8e Baldr: decode Code section header in DecodeModuleEnvironment (r=lth)

https://hg.mozilla.org/mozilla-central/rev/62fc2f51d566 https://hg.mozilla.org/mozilla-central/rev/13b556ec5a8e