1. 22 Jul, 2022 19 commits
  2. 21 Jul, 2022 18 commits
  3. 20 Jul, 2022 3 commits
    • Milad Fa's avatar
      PPC [liftoff]: Implement simd load and store · 6934107e
      Milad Fa authored
      Change-Id: Ia45248a3d8566dbb4f2702a8b1ea6959157dc76b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776949
      Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#81857}
      6934107e
    • Seth Brenith's avatar
      Fix v8windbg Locals pane behavior · 607ad422
      Seth Brenith authored
      Background:
      
      In order to show custom content in the "Locals" pane in WinDbg, v8windbg
      replaces the getter function for a built-in debug model property named
      "Debugger.Models.StackFrame.LocalVariables". This is the property that
      the debugger fetches when determining what to display in "Locals". The
      new implementation of that getter, V8LocalVariables::GetValue, can
      either call the original getter (so that WinDbg displays the usual
      content for normal C++ frames) or produce a custom result (for builtins
      and JIT-compiled JS frames).
      
      The current problem:
      
      In new builds of WinDbg, users of v8windbg no longer see any content in
      the Locals pane for stack frames that correspond to builtins or
      JIT-compiled code. This is because of a behavior change in WinDbg:
      previously, attempting to get Debugger.Models.StackFrame.LocalVariables
      would eagerly attempt to find the symbols for the frame and return an
      error code if symbols were not found, but now it returns a lazy object
      which does not perform symbol lookup until you iterate its properties.
      V8LocalVariables::GetValue currently starts with an early-exit path
      based on checking whether the original getter succeeded, so the new lazy
      implementation causes us to always take that early exit.
      
      Proposed fix:
      
      Rather than relying on the return value from the original getter, which
      is not guaranteed to work consistently, we can base our decisions on the
      instruction pointer. If it points outside any module, or if it points to
      within a function in the module containing V8 whose name starts with
      "Builtins_", then we can build a custom result for the Locals pane.
      
      Change-Id: I6644071d5d83a25b964d9f4018265532528cc85c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3759228Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#81856}
      607ad422
    • Dominik Inführ's avatar
      [heap] Add thread-safe shared barrier for code objects · aee4f595
      Dominik Inführ authored
      In order to make the shared code write barrier thread-safe, we simply
      lock the page mutex when appending to the typed_slot_set. We can later
      improve this when performance isn't good enough.
      
      Bug: v8:13018
      Change-Id: I5e12f83f459f8976c22ec488cfa9b6f16d4a8a8e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763867Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81855}
      aee4f595