1. 17 Nov, 2016 1 commit
    • kozyatinskiy's avatar
      [inspector] introduced Script::TYPE_INSPECTOR · 6808ec1f
      kozyatinskiy authored
      Inspector uses this type for all internal scripts, e.g. injected-script-source.js. Scripts with new type are not reported by remote debugging protocol, frames from them are ignored.
      
      CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
      BUG=none
      R=yangguo@chromium.org,dgozman@chromium.org
      
      Review-Url: https://codereview.chromium.org/2499273003
      Cr-Commit-Position: refs/heads/master@{#41056}
      6808ec1f
  2. 16 Nov, 2016 3 commits
  3. 15 Nov, 2016 2 commits
    • cbruni's avatar
      [elements] Precisely estimate elements size as last resort · 14c6a651
      cbruni authored
      In case of an allocation failure in for-in over holey elements, use precise
      number of elements to allocate a smaller buffer for the collected indices.
      
      Drive-by-fix: make is_the_hole accept the isolate for faster checks.
      
      BUG=chromium:609761
      
      Review-Url: https://codereview.chromium.org/2041963003
      Cr-Commit-Position: refs/heads/master@{#41010}
      14c6a651
    • clemensh's avatar
      [wasm] Allocate a single script per wasm module · 32077e01
      clemensh authored
      Before, we allocated one script per function per instance, and each
      script referenced the wasm instance and the function index. Now we only
      allocate one script per compiled wasm module, so the script also only
      references this WasmCompiledModule, which causes changes to many interfaces.
      
      Instead of fixing the disassemble API only used via debug.js, I decided
      to drop it for now. Some later CL will reintroduce it via
      DebugInterface.
      
      BUG=v8:5530,chromium:659715
      R=yangguo@chromium.org, titzer@chromium.org
      CC=jgruber@chromium.org
      
      Review-Url: https://codereview.chromium.org/2493823003
      Cr-Commit-Position: refs/heads/master@{#41004}
      32077e01
  4. 14 Nov, 2016 2 commits
    • tebbi's avatar
      This CL enables precise source positions for all V8 compilers. It merges... · c3a6ca68
      tebbi authored
      This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset.
      SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
       - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
       - The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
      Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
      
      If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
      So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
      
      All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
      
      At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
      
      I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
      
      The following additional changes were necessary:
       - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
       - The class HPositionInfo was effectively dead code and is now removed.
       - SourcePosition has new printing and information facilities, including computing a full inlining stack.
       - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
       - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
       - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
       - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
      
      BUG=v8:5432
      
      Review-Url: https://codereview.chromium.org/2451853002
      Cr-Commit-Position: refs/heads/master@{#40975}
      c3a6ca68
    • caitp's avatar
      [builtins] implement JSBuiltinReducer for ArrayIteratorNext() · 7f21e67b
      caitp authored
      Adds a protector cell to prevent inlining (which will likely lead to deopt
      loops) when a JSArrayIterator's array transitions from a fast JSArray to a
      slow JSArray (such as, when the array is touched during iteration in a way
      which triggers a map transition).
      
      Also adds TODO comments relating to the spec update proposed by Dan at
      https://github.com/tc39/ecma262/pull/724
      
      BUG=v8:5388
      R=bmeurer@chromium.org, mstarzinger@chromium.org
      TBR=hpayer@chromium.org, ulan@chromium.org
      
      Review-Url: https://codereview.chromium.org/2484003002
      Cr-Commit-Position: refs/heads/master@{#40970}
      7f21e67b
  5. 11 Nov, 2016 1 commit
    • gsathya's avatar
      [promises] Remove one runtime call to create_resolving_functions · ec61e6b4
      gsathya authored
      - Creates a new promise-utils.{h, cc} which refactors out the
      logic to create resolving functions. This is shared between the
      runtime functions and builtins.
      
      - Changes PromiseResolveThenableJobInfo to store the context
      since we no longer create the resolving functions in JS.
      
      - Changes EnqueuPromiseResolveThenableJob to take in the promise and
        not the callbacks.
      
      BUG=v8:5343
      
      Review-Url: https://codereview.chromium.org/2487053002
      Cr-Commit-Position: refs/heads/master@{#40941}
      ec61e6b4
  6. 10 Nov, 2016 1 commit
  7. 09 Nov, 2016 1 commit
  8. 07 Nov, 2016 2 commits
  9. 04 Nov, 2016 4 commits
  10. 02 Nov, 2016 1 commit
  11. 01 Nov, 2016 1 commit
  12. 31 Oct, 2016 2 commits
  13. 28 Oct, 2016 1 commit
  14. 27 Oct, 2016 1 commit
  15. 26 Oct, 2016 1 commit
  16. 25 Oct, 2016 4 commits
  17. 21 Oct, 2016 1 commit
    • leszeks's avatar
      [compiler] Mark shared functions for optimization · 4a31323e
      leszeks authored
      The current method of marking functions for optimization, which replaces
      the JSFunction's code object with one that triggers optimization, would
      never allow unnamed functions to be optimized. This is an issue for a
      style of programming which heavily relies on passing around closures.
      
      This patch sets a bit on the SharedFunctionInfo when a JSFunction is
      marked. When another JSFunction referring to the same SharedFunctionInfo
      is lazily compiled, it immediately triggers a non-concurrent optimize.
      
      BUG=v8:5512
      
      Review-Url: https://chromiumcodereview.appspot.com/2437043002
      Cr-Commit-Position: refs/heads/master@{#40506}
      4a31323e
  18. 19 Oct, 2016 1 commit
  19. 18 Oct, 2016 2 commits
  20. 17 Oct, 2016 4 commits
  21. 14 Oct, 2016 2 commits
  22. 13 Oct, 2016 2 commits