1. 18 Jan, 2018 1 commit
  2. 11 Jan, 2018 1 commit
  3. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored
      This patch normalizes the casing of hexadecimal digits in escape
      sequences of the form `\xNN` and integer literals of the form
      `0xNNNN`.
      
      Previously, the V8 code base used an inconsistent mixture of uppercase
      and lowercase.
      
      Google’s C++ style guide uses uppercase in its examples:
      https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
      
      Moreover, uppercase letters more clearly stand out from the lowercase
      `x` (or `u`) characters at the start, as well as lowercase letters
      elsewhere in strings.
      
      BUG=v8:7109
      TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
      NOPRESUBMIT=true
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
      Reviewed-on: https://chromium-review.googlesource.com/804294
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2
  4. 21 Nov, 2017 1 commit
  5. 11 Oct, 2017 1 commit
  6. 28 Sep, 2017 1 commit
  7. 11 Sep, 2017 1 commit
  8. 08 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [fuzzer] Fix segfault · 3ced15cb
      Clemens Hammacher authored
      Even though we were generating additional arguments with default value
      in the case that the caller was not providing enough, we then passed
      the original pointer, leading to potential out-of-bounds accesses.
      
      R=ahaas@chromium.org
      
      Bug: chromium:763294,chromium:763297
      Change-Id: Id18622d0d40e0408e26a5fc6f97494b5f9e18d17
      Reviewed-on: https://chromium-review.googlesource.com/657699Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47930}
      3ced15cb
  9. 07 Sep, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Avoid executing infinite loops in the wasm fuzzers · 7b53a0e0
      Andreas Haas authored
      The wasm-async fuzzer uses the bytes provided by the fuzzer engine
      directly as wasm module bytes, compiles them with async compilation, and
      then tries to execute the "main" function of the module. This "main"
      can have an infinite loop which causes a timeout in the fuzzer. With
      this CL the "main" function is first executed with the interpreter. If
      the execution in the interpreter finishes within 16k steps, which means
      that there is no infinite loop, also the compiled code is executed.
      
      I added the raw fuzzer input as a test case because in this case I
      really want to test the fuzzer and not V8.
      
      R=clemensh@chromium.org
      
      Bug: chromium:761784
      Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162
      Reviewed-on: https://chromium-review.googlesource.com/651046
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47874}
      7b53a0e0
  10. 04 Sep, 2017 1 commit
  11. 10 Aug, 2017 1 commit
  12. 07 Aug, 2017 1 commit
    • Mircea Trofin's avatar
      [wasm] Clarify source of runtime information for interpreter. · 3f1e32b3
      Mircea Trofin authored
      This is part of the effort to consolidate the ownership of
      wasm instantiation/specialization parameters.
      
      This change is focused solely on the interpreter part of that effort, to
      verify we're not regressing performance in interpreter benchmarks.
      
      There are two aspects being addressed:
      - dataflow-wise, we always fetch the interpreter's memory view from the
      runtime objects (i.e. WasmInstanceObject/WasmCompiledModule). This is
      consistent with how other instance-specific information is obtained
      (e.g. code, indirect functions).
      
      - representation-wise, we do not reuse ModuleEnv/WasmInstance just for
      the memory view, because it is surprising that other instance info isn't
      accessed from there. 
      
      Bug: 
      Change-Id: I536fbffd8e1f142a315fa1770ba9b08319f56a8e
      Reviewed-on: https://chromium-review.googlesource.com/602083Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47205}
      3f1e32b3
  13. 18 Jul, 2017 1 commit
  14. 14 Jul, 2017 1 commit
    • Clemens Hammacher's avatar
      Reland "[wasm] Don't store global handles in the interpreter" · b53141ec
      Clemens Hammacher authored
      This is a reland of 5648aad5.
      Previous compile error should be fixed by disabling strict aliasing
      assumptions on gyp: https://chromium-review.googlesource.com/c/571806
      
      Original change's description:
      > [wasm] Don't store global handles in the interpreter
      > 
      > Storing global handles in the interpreter is dangerous, because the
      > global handles are strong roots into the heap. The interpreter itself is
      > referenced from the heap via a Managed. Hence the interpreter keeps the
      > instance alive, while the instance keeps the Managed alive. So the GC
      > will never collect them.
      > 
      > This CL refactors this to only store the handle to the instance object
      > while executing in the interpreter, and clearing it when returning.
      > It also removes the cache of import wrappers, as it should not be
      > performance critical, but keeps lots of objects alive. If it turns out
      > to be performance critical, we will have to reintroduce such a cache
      > stored in the WasmDebugInfo object.
      > 
      > R=titzer@chromium.org
      > CC=ahaas@chromium.org
      > 
      > Bug: chromium:610330
      > Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
      > Reviewed-on: https://chromium-review.googlesource.com/567058
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46629}
      
      TBR=titzer@chromium.org
      
      Bug: chromium:610330
      Change-Id: Ic7836b1b1a044a89f2138f0c76f92acd3a1b2f2b
      Reviewed-on: https://chromium-review.googlesource.com/570578
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46679}
      b53141ec
  15. 13 Jul, 2017 2 commits
    • Clemens Hammacher's avatar
      Revert "[wasm] Don't store global handles in the interpreter" · 199a26f7
      Clemens Hammacher authored
      This reverts commit 5648aad5.
      
      Reason for revert: Compile error on mips:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/10732
      
      Original change's description:
      > [wasm] Don't store global handles in the interpreter
      > 
      > Storing global handles in the interpreter is dangerous, because the
      > global handles are strong roots into the heap. The interpreter itself is
      > referenced from the heap via a Managed. Hence the interpreter keeps the
      > instance alive, while the instance keeps the Managed alive. So the GC
      > will never collect them.
      > 
      > This CL refactors this to only store the handle to the instance object
      > while executing in the interpreter, and clearing it when returning.
      > It also removes the cache of import wrappers, as it should not be
      > performance critical, but keeps lots of objects alive. If it turns out
      > to be performance critical, we will have to reintroduce such a cache
      > stored in the WasmDebugInfo object.
      > 
      > R=​titzer@chromium.org
      > CC=ahaas@chromium.org
      > 
      > Bug: chromium:610330
      > Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
      > Reviewed-on: https://chromium-review.googlesource.com/567058
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46629}
      
      TBR=titzer@chromium.org,clemensh@chromium.org
      
      Change-Id: Ifadfb885f937f37bb3eab4732a97f20ff40c2583
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:610330
      Reviewed-on: https://chromium-review.googlesource.com/569962Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46630}
      199a26f7
    • Clemens Hammacher's avatar
      [wasm] Don't store global handles in the interpreter · 5648aad5
      Clemens Hammacher authored
      Storing global handles in the interpreter is dangerous, because the
      global handles are strong roots into the heap. The interpreter itself is
      referenced from the heap via a Managed. Hence the interpreter keeps the
      instance alive, while the instance keeps the Managed alive. So the GC
      will never collect them.
      
      This CL refactors this to only store the handle to the instance object
      while executing in the interpreter, and clearing it when returning.
      It also removes the cache of import wrappers, as it should not be
      performance critical, but keeps lots of objects alive. If it turns out
      to be performance critical, we will have to reintroduce such a cache
      stored in the WasmDebugInfo object.
      
      R=titzer@chromium.org
      CC=ahaas@chromium.org
      
      Bug: chromium:610330
      Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
      Reviewed-on: https://chromium-review.googlesource.com/567058Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46629}
      5648aad5
  16. 10 Jul, 2017 1 commit
  17. 29 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Use pending exceptions consistently · d6aed443
      Clemens Hammacher authored
      In our internal code, we should only use pending exceptions. They will
      be converted to scheduled exceptions on the API boundary.
      Hence, the ErrorThrower just sets a pending exception; it should never
      have to think about scheduled exceptions. The new
      ScheduledErrorThrower inherits from ErrorThrower and reschedules any
      pending exceptions in its destructor (turning them into scheduled
      exceptions).
      In some situations, there might already be a scheduled exception, e.g.
      when calling other API methods (v8::Value::Get). In this case, the
      ErrorThrower should also not set another pending exception. For the
      reasons mentioned above, this can only be handled in the
      ScheduledErrorThrower, which is used the API methods.
      
      This fixes one DCHECK failure and one TODO about scheduled exceptions
      if no instance can be created, because the start function throws.
      
      R=mtrofin@chromium.org, mstarzinger@chromium.org
      BUG=v8:6232,chromium:736256
      
      Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2
      Reviewed-on: https://chromium-review.googlesource.com/548641
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46314}
      d6aed443
  18. 27 Jun, 2017 1 commit
  19. 26 Jun, 2017 1 commit
  20. 23 Jun, 2017 2 commits
  21. 22 Jun, 2017 1 commit
    • kschimpf's avatar
      Fix use of history timers in background threads. · d4a10807
      kschimpf authored
      HistoryTimer's can't run in the background because they use a timer
      with a simple api of Start() and Stop(). This CL fixes this problem
      by building a base class TimedHistogram that doesn't have a timer.
      
      The class HistoryTimer is modified to use this base class so that
      uses that run on the foreground thread do not need to be modified.
      
      It also adds a new class TimedHistogramScope that defines the timer
      in this class. This allows the corresopnding TimedHistogram class to
      be type safe.
      
      BUG=v8:6361
      
      Review-Url: https://codereview.chromium.org/2929853003
      Cr-Commit-Position: refs/heads/master@{#46150}
      d4a10807
  22. 21 Jun, 2017 1 commit
  23. 12 Jun, 2017 3 commits
  24. 09 Jun, 2017 1 commit
  25. 08 May, 2017 1 commit
  26. 28 Apr, 2017 1 commit
  27. 10 Apr, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Refactor wasm::Result type · d50ebde7
      Clemens Hammacher authored
      - Store std::string instead of std::unique_ptr<char[]> for the error
        message.
      - Remove ErrorCode, which was just kSuccess and kError anyway. Error is
        now detected on whether error_msg_ is empty or not.
      - Refactor constructors for perfect forwarding; this will allow us to
        implement Result<std::unique_ptr<X*>>.
      - Refactor Decoder::toResult for perfect forwarding.
      - Remove output operators (operator<<) for Result; it was only used in
        the error case anyway. Print error message directly instead.
        The operator was problematic since it assumed the existence of an
        output operator for every T which is used in Result<T>.
      - Remove ModuleError and FunctionError, introduce general static
        Result<T>::Error method instead.
      
      R=ahaas@chromium.org
      
      Change-Id: I1e0f602a61ee9780fee2a3ed33147d431fb092ba
      Reviewed-on: https://chromium-review.googlesource.com/472748
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44518}
      d50ebde7
  28. 06 Apr, 2017 1 commit
  29. 23 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Implement indirect function calls · b8f88601
      Clemens Hammacher authored
      This CL adds support for indirect function calls to the interpreter. It
      can indirectly call other wasm function in the same instance, which are
      then executed in the interpreter, or call imported functions.
      
      Implementing this required some refactoring:
      - The wasm interpreter now unwraps import wrappers on demand, instead
        of unwrapping all of them on instantiation and storing a vector of
        handles. This also avoids the DeferredHandleScope completely, instead
        we just store two global handles in the code map.
      - The interpreter gets the code table, function tables and signature
        tables directly from the attached wasm instance object. This ensures
        that the interpreter sees all updates to tables that might have been
        performed by external code.
      - There is now common functionality for calling a code object. This is
        used for direct calls to imported functions and for all indirect
        calls. As these code objects can also be wasm functions which should
        be executed in the interpreter itself, I introduce a struct to hold
        the outcome of calling the code object, or a pointer to
        InterpreterCode to be called in the interpreter.
      
      R=ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: I20fb2ea007e79e5fcff9afb4b1ca31739ebcb83f
      Reviewed-on: https://chromium-review.googlesource.com/458417
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44059}
      b8f88601
  30. 14 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Cleanup wasm interpreter · 0a4c5c44
      Clemens Hammacher authored
      This is a cleanup in preparation to implement calling imported
      functions via the wasm interpreter.
      For imported functions, we do not create entries in the
      interpreter_code_ vector any more.
      
      I also simplified the interface and removed unused or redundant return
      values. More things are now DCHECKed instead of bailing out.
      
      Also, we previously had two PushFrame methods: One is supposed to
      initialize the interpreter from external code (i.e. adds the first
      frame to the stack), the other one is used to push new frames on the
      frame stack for called functions. This CL renames the first to
      InitFrame, and makes it use the second one. The other remaining user is
      the DoCall method.
      
      R=titzer@chromium.org
      BUG=v8:5822
      
      Change-Id: Id09ff1e3256428fbd8c955e4664507a0c3167e53
      Reviewed-on: https://chromium-review.googlesource.com/453482
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43793}
      0a4c5c44
  31. 20 Feb, 2017 1 commit
  32. 13 Feb, 2017 1 commit
  33. 24 Jan, 2017 1 commit
  34. 16 Jan, 2017 1 commit
  35. 12 Jan, 2017 1 commit
  36. 20 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Introduce WasmSharedModuleData and refactor other objects · 081ac370
      clemensh authored
      The new object will hold information which is shared by all clones of a
      WasmCompiledModule, e.g. the decoded asm.js offset table, and in the
      future also breakpoints. From there, we can set them on each new
      instantiation of any clone.
      
      While already changing lots of the code base, I also renamed all
      getters from "get_foo" to "foo", to conform to the style guide.
      
      R=titzer@chromium.org, yangguo@chromium.org
      BUG=v8:5732
      
      Review-Url: https://codereview.chromium.org/2591653002
      Cr-Commit-Position: refs/heads/master@{#41862}
      081ac370