1. 26 Jul, 2016 1 commit
  2. 08 Jul, 2016 1 commit
  3. 30 Jun, 2016 1 commit
    • jgruber's avatar
      [builtins] New frame type for exits to C++ builtins · 5febc27b
      jgruber authored
      Prior to this commit, calls to C++ builtins created standard exit
      frames, which are skipped when constructing JS stack traces. In order to
      show these calls on traces, we introduce a new builtin exit frame type.
      
      Builtin exit frames contain target and new.target on the stack and are
      not skipped during stack trace construction.
      
      BUG=v8:4815
      R=bmeurer@chromium.org, yangguo@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg
      
      Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
      Review-Url: https://codereview.chromium.org/2090723005
      Cr-Original-Commit-Position: refs/heads/master@{#37384}
      Cr-Commit-Position: refs/heads/master@{#37416}
      5febc27b
  4. 29 Jun, 2016 2 commits
  5. 19 May, 2016 1 commit
  6. 10 May, 2016 1 commit
  7. 03 May, 2016 1 commit
  8. 30 Apr, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Run everything after representation selection concurrently. · d1b3d426
      bmeurer authored
      Further refactor the pipeline to even run the first scheduler (part of
      the effect control linearization) concurrently. This temporarily
      disables most of the write barrier elimination, but we will get back to
      that later.
      
      Drive-by-fix: Remove the dead code from ChangeLowering, and stack
      allocate the Typer in the pipeline. Also migrate the AllocateStub to a
      native code builtin, so that we have the code object + a handle to it
      available all the time.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
      R=mstarzinger@chromium.org
      BUG=v8:4969
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1926023002
      Cr-Commit-Position: refs/heads/master@{#35918}
      d1b3d426
  9. 19 Apr, 2016 1 commit
  10. 15 Apr, 2016 1 commit
  11. 06 Apr, 2016 1 commit
    • bmeurer's avatar
      [generators] Decouple generator resume from fullcodegen. · 974721c6
      bmeurer authored
      Introduce a ResumeGeneratorTrampoline, which does the actual stack state
      reconstruction (currently always restores a fullcodegen frame), and
      introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
      %GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
      this native builtin.
      
      Also unify the flooding in case of step-in to always work based on
      JSFunction and remove the special casing for JSGeneratorObject.
      
      R=mstarzinger@chromium.org, neis@chromium.org
      TBR=rossberg@chromium.org
      BUG=chromium:513471
      LOG=n
      
      Review URL: https://codereview.chromium.org/1865833002
      
      Cr-Commit-Position: refs/heads/master@{#35283}
      974721c6
  12. 29 Mar, 2016 1 commit
    • titzer's avatar
      [wasm] Fix arm64 frame alignment. · c9f59780
      titzer authored
          In JavaScript code and stubs, JSSP mirrors the CSP but may be unaligned.
          But in WASM code only CSP is used, like native code, and it must be
          aligned.
          Calls into WASM from JS need to carefully align the C stack
          pointer (csp) and restore the previous JSSP, while calls from WASM
          to JS need to compute a new JSSP and restore their CSP after the
          call.
      
      R=ahaas@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1811283003
      
      Cr-Commit-Position: refs/heads/master@{#35096}
      c9f59780
  13. 21 Mar, 2016 1 commit
    • bmeurer's avatar
      [stubs] Split ToNumberStub into reusable subparts. · b7aa4c3a
      bmeurer authored
      Split ToNumberStub into the entry ToNumberStub, and two new stubs,
      StringToNumberStub and NonNumberToNumberStub, which can be used when we
      already know something about the input (i.e. in various branches of the
      code stubs, or in TurboFan graphs).
      
      Also introduce an appropriate StringToNumber simplified operator for
      TurboFan, that is pure and is lowered to an invocation of the newly
      added StringToNumberStub.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1818923002
      
      Cr-Commit-Position: refs/heads/master@{#34922}
      b7aa4c3a
  14. 08 Mar, 2016 1 commit
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored
      Before this CL, various code stubs used different techniques
      for marking their frames to enable stack-crawling and other
      access to data in the frame. All of them were based on a abuse
      of the "standard" frame representation, e.g. storing the a
      context pointer immediately below the frame's fp, and a
      function pointer after that. Although functional, this approach
      tends to make stubs and builtins do an awkward, unnecessary
      dance to appear like standard frames, even if they have
      nothing to do with JavaScript execution.
      
      This CL attempts to improve this by:
      
      * Ensuring that there are only two fundamentally different
        types of frames, a "standard" frame and a "typed" frame.
        Standard frames, as before, contain both a context and
        function pointer. Typed frames contain only a minimum
        of a smi marker in the position immediately below the fp
        where the context is in standard frames.
      * Only interpreted, full codegen, and optimized Crankshaft and
        TurboFan JavaScript frames use the "standard" format. All
        other frames use the type frame format with an explicit
        marker.
      * Typed frames can contain one or more values below the
        type marker. There is new magic macro machinery in
        frames.h that simplifies defining the offsets of these fields
        in typed frames.
      * A new flag in the CallDescriptor enables specifying whether
        a frame is a standard frame or a typed frame. Secondary
        register location spilling is now only enabled for standard
        frames.
      * A zillion places in the code have been updated to deal with
        the fact that most code stubs and internal frames use the
        typed frame format. This includes changes in the
        deoptimizer, debugger, and liveedit.
      * StandardFrameConstants::kMarkerOffset is deprecated,
        (CommonFrameConstants::kContextOrFrameTypeOffset
        and StandardFrameConstants::kFrameOffset are now used
        in its stead).
      
      LOG=N
      
      Review URL: https://codereview.chromium.org/1696043002
      
      Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  15. 07 Mar, 2016 1 commit
    • ishell's avatar
      [crankshaft] Support ES6 tail call elimination. · 22938040
      ishell authored
      HInvokeFunction and HApplyArguments instructions now support tail calling.
      
      Inlining of calls at tail position is not supported yet and therefore still disabled.
      
      The tail-call-megatest was modified so that the usages of "arguments" object do not disable Crankshaft.
      
      TBR=bmeurer@chromium.org
      BUG=v8:4698
      LOG=N
      
      Review URL: https://codereview.chromium.org/1760253003
      
      Cr-Commit-Position: refs/heads/master@{#34542}
      22938040
  16. 24 Feb, 2016 1 commit
  17. 19 Feb, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce a dedicated FastNewObjectStub. · ba2077aa
      bmeurer authored
      Move the already existing fast case for %NewObject into a dedicated
      FastNewObjectStub that we can utilize in places where we would otherwise
      fallback to %NewObject immediately, which is rather expensive.
      
      Also use FastNewObjectStub as the generic implementation of JSCreate,
      which should make constructor inlining based on SharedFunctionInfo (w/o
      specializing to a concrete closure) viable soon.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1708313002
      
      Cr-Commit-Position: refs/heads/master@{#34136}
      ba2077aa
  18. 15 Feb, 2016 1 commit
  19. 10 Feb, 2016 1 commit
    • mlippautz's avatar
      [heap] Move to page lookups for SemiSpace, NewSpace, and Heap containment methods · cfbd2561
      mlippautz authored
      Preparing the young generation for (real) non-contiguous backing memory, this
      change removes object masks that are used to compute containment in semi and new
      space. The masks are replaced by lookups for object tags and page headers, where
      possible.
      
      Details:
      - Use the fast checks (page header lookups) for containment in regular code.
      - Use the slow version that masks out the page start adress and iterates all
        pages of a space for debugging/verification.
      - The slow version works for off-heap/unmapped memory.
      - Encapsulate all checks for the old->new barrier in Heap::RecordWrite().
      
      BUG=chromium:581412
      LOG=N
      
      Review URL: https://codereview.chromium.org/1632913003
      
      Cr-Commit-Position: refs/heads/master@{#33857}
      cfbd2561
  20. 04 Feb, 2016 1 commit
  21. 02 Feb, 2016 1 commit
  22. 21 Jan, 2016 1 commit
    • bmeurer's avatar
      [for-in] Sanitize for-in optimizations and fix bailout points. · f48bf12f
      bmeurer authored
      The PrepareId bailout location was used incorrectly in Crankshaft and,
      as it turns out, is not required anyway (once you do it right). Also
      there was some premature optimization going on with the CheckEnumCache
      (trying to load null from roots only once), plus we can be smarter about
      the null/undefined check anyway.
      
      The idea behind this changes is to prepare unification of the two
      different ForInPrepare implementations that we now have, with the end
      result being that we only use the new implementation that was recently
      added for the interpreter.
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1618613002
      
      Cr-Commit-Position: refs/heads/master@{#33426}
      f48bf12f
  23. 20 Jan, 2016 1 commit
  24. 15 Jan, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add ForInPrepare runtime function which returns a ObjectTriple. · 84f8a506
      rmcilroy authored
      Adds a ForInPrepare Runtime function which returns a triple of
      cache_type, cache_array and cache_length.
      
      This requires adding support to CEntryStub to call runtime functions
      which return a ObjectTriple - a struct containing three Object*
      pointers. Also did some cleanup of the x64 CEntryStub to avoid
      replicated code.
      
      Replaces the interpreter's use of the ad-hock InterpreterForInPrepare
      Runtime function with ForInPrepare in preparation for fixing deopt in
      BytecodeGraphBuilder for ForIn (which will be done in a followup CL).
      
      MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1576093004
      
      Cr-Commit-Position: refs/heads/master@{#33334}
      84f8a506
  25. 13 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Number constructor similar to String constructor. · 322ffda3
      bmeurer authored
      Also migrate the Number constructor to a native builtin, using the
      same mechanism already used by the String constructor. Otherwise just
      parsing and compiling the Number constructor to optimized code already
      eats 2ms on desktop for no good reason, and the resulting optimized
      code is not even close to awesome.
      
      Drive-by-fix: Use correct context for the [[Construct]] case of the
      String constructor as well, and share some code with it.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1573243009
      
      Cr-Commit-Position: refs/heads/master@{#33265}
      322ffda3
  26. 11 Jan, 2016 1 commit
  27. 30 Dec, 2015 1 commit
  28. 29 Dec, 2015 1 commit
  29. 27 Dec, 2015 2 commits
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · 97def807
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      Cr-Commit-Position: refs/heads/master@{#33042}
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33044}
      97def807
    • bmeurer's avatar
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound... · 1cf8b105
      bmeurer authored
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ )
      
      Reason for revert:
      Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
      
      Original issue's description:
      > [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
      >
      > According to the ES2015 specification, bound functions are exotic
      > objects, and thus don't need to be implemented as JSFunctions. So
      > we introduce a new JSBoundFunction type to represent bound functions
      > and make them optimizable. This already improves the performance of
      > calling or constructing bound functions by 10-100x depending on the
      > use case because we avoid the crazy dance between JavaScript and C++
      > that was implemented in v8natives.js previously.
      >
      > There's still room for improvement in the performance of actually
      > creating bound functions, which is also relevant in practice, but
      > we already have a plan how to accomplish that later.
      >
      > The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      >
      > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      > BUG=chromium:535408, chromium:571299, v8:4629
      > LOG=n
      >
      > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      > Cr-Commit-Position: refs/heads/master@{#33042}
      
      TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:535408, chromium:571299, v8:4629
      
      Review URL: https://codereview.chromium.org/1552473002
      
      Cr-Commit-Position: refs/heads/master@{#33043}
      1cf8b105
  30. 26 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · ca8623ea
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33042}
      ca8623ea
  31. 23 Dec, 2015 1 commit
  32. 17 Dec, 2015 1 commit
    • Benedikt Meurer's avatar
      [runtime] Drop FIRST/LAST_NONCALLABLE_SPEC_OBJECT instance type range. · aafc3e54
      Benedikt Meurer authored
      The FIRST-LAST_NONCALLABLE_SPEC_OBJECT_TYPE range was accidentially used
      in field type tracking, where we should check for JSReceiver instead
      (there's no need to exclude JSProxy or JSFunction from tracking).
      
      And the use in %_ClassOf was actually wrong and didn't match the C++
      implementation in JSReceiver::class_name() anymore. Now it's consistent
      again.
      
      R=yangguo@chromium.org
      BUG=chromium:535408
      LOG=n
      
      Review URL: https://codereview.chromium.org/1535523003 .
      
      Cr-Commit-Position: refs/heads/master@{#32926}
      aafc3e54
  33. 03 Dec, 2015 1 commit
  34. 27 Nov, 2015 3 commits
  35. 26 Nov, 2015 1 commit
  36. 25 Nov, 2015 1 commit