• Mircea Trofin's avatar
    [wasm] Consolidate ownership of instantiation/specialization parameters · f9d4090b
    Mircea Trofin authored
    This CL consolidates ownership of parameters used to compile code (which
    we always specialize) in 2 places:
    - ModuleEnv for compile-time data
    - WasmCompiledModule for runtime data
    
    The parameters in question are: memory size and start; globals start; 
    address of indirect function tables (and their signatures, respectively); 
    and address to be used for wasm call sites.
    
    Ideally, we'd collapse this down to one place, however, we need
    specialization data to survive serialization. We can achieve this we get off 
    the GC heap and use a different wasm code serializer.
    
    The CL:
    - removes aliasing of parts of the specialization data, and moves
    to using ModuleEnv as a token of passing around compile-time data, instead
    of a mixture of ModuleEnv, WasmInstance, and some other structures. ModuleEnv
    is responsible for providing a consistent view of the specialization data,
    e.g. valid memory sizes (multiples of page size), and matching sized function
    tables and signatures.
    
    - removes WasmInstance, as its data is now contained by ModuleEnv.
    
    - removes ModuleBytesEnv. We now pass the wire bytes explicitly. They can't
    always be assumed as present (e.g. streaming compilation), and probably more
    refactoring may need to happen once streaming compilation lands and we
    better understand our dependencies.
    
    Change-Id: Id7e6f2cf29e51b5756eee8b6f8827fb1f375e5c3
    Reviewed-on: https://chromium-review.googlesource.com/592531
    Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
    Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#47229}
    f9d4090b
module-decoder.h 5.49 KB