1. 17 Aug, 2016 1 commit
    • rmcilroy's avatar
      Avoid accessing Isolate in source position logging. · b8b4a443
      rmcilroy authored
      Now that all backends use the source position builder to record source
      positions, simplify the code line logging events to take a source
      position table on code creation. This means that the source position
      table builder no longer needs to access the isolate until the table is
      generated. This is required for off-thread bytecode generation.
      
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2248673002
      Cr-Commit-Position: refs/heads/master@{#38676}
      b8b4a443
  2. 12 Aug, 2016 1 commit
    • jkummerow's avatar
      [regexp][liveedit] Fix inconsistent JSArrays · bb9707c8
      jkummerow authored
      The hand-written KeyedLoadIC_Megamorphic stub didn't care about JSArray
      lengths, which made it lenient towards said lengths being wrong, but it
      will soon fix that bug and thereby become more strict.
      
      LiveEdit: factory->NewJSArray(capacity) doesn't set a length, so set it
      manually.
      RegExp: to avoid having to take care of array length updating in the
      RegExpExecStub, just use a JSObject instead.
      
      Review-Url: https://codereview.chromium.org/2244673002
      Cr-Commit-Position: refs/heads/master@{#38624}
      bb9707c8
  3. 10 Aug, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Add ability to preserve bytecode. · 9e60db1f
      mstarzinger authored
      This adds the --ignition-preserve-bytecode flag which will preserve any
      existing bytecode, even if a tier-up to baseline code is performed. This
      is preparatory work in order to allow mixed stacks where bytecode and
      baseline code can be active at the same time.
      
      It also adds a {HasBaselineCode} predicate symmetric to the existing
      {HasBytecodeArray} predicate. Both predicates are independent and any
      combination of answers is valid.
      
      Further adaptation of the rest of the runtime will be done step-wise in
      follow-up changes.
      
      R=yangguo@chromium.org
      BUG=v8:5265
      
      Review-Url: https://codereview.chromium.org/2224923003
      Cr-Commit-Position: refs/heads/master@{#38540}
      9e60db1f
  4. 09 Aug, 2016 1 commit
  5. 01 Aug, 2016 1 commit
  6. 28 Jul, 2016 1 commit
  7. 25 Jul, 2016 1 commit
    • nikolaos's avatar
      [parser] Refactor AstTraversalVisitor · ad6ea932
      nikolaos authored
      This patch parametrizes AstTraversalVisitor by the actual subclass,
      in a similar way as AstVisitor is parametrized.  This allows a
      subclass to, e.g., override the Visit method and still use the
      traversal mechanism.  It also allows the subclass to override the
      specific visiting methods, without them being virtual.
      
      This patch also removes AstExpressionVisitor, subsuming its
      functionality in AstTraversalVisitor.
      
      R=adamk@chromium.org, verwaest@chromium.org
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2169833002
      Cr-Commit-Position: refs/heads/master@{#37998}
      ad6ea932
  8. 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
  9. 29 Jun, 2016 3 commits
  10. 28 Jun, 2016 1 commit
  11. 20 Jun, 2016 1 commit
  12. 15 Jun, 2016 1 commit
  13. 14 Jun, 2016 1 commit
  14. 08 Jun, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Improve contract for Compiler::CompileDebugCode. · 80b98da2
      mstarzinger authored
      This changes the contract for the aforementioned API function to be more
      permissive and allow callers to call it with less restrictions. The new
      contract is:
      
      a) For so far un-compiled functions, the compiler is free to choose the
         backend according to other decision criteria. Debug code can hence be
         provided by either Ignition or FullCodegen.
      b) For compiled functions, the compiler will provide debug code within
         the same tier as existing code. For Ignition the generated code will
         be equivalent to the old one. For FullCodegen the code will contain
         debug information and debug break slots.
      
      Concretely this fixes an issue where generator or async functions might
      have been compiled with an unexpected backend, due to the fact that the
      API method in question was always providing FullCodegen code.
      
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2044063002
      Cr-Commit-Position: refs/heads/master@{#36808}
      80b98da2
  15. 06 Jun, 2016 1 commit
  16. 31 May, 2016 1 commit
    • littledan's avatar
      [esnext] Fix various callsites to use is_resumable, not is_generator · 46253e74
      littledan authored
      Async functions are built out of generators, but the
      SharedFunctionInfo returns false for is_generator. is_resumable is
      the broader query. This patch fixes many parts of V8 to refer
      to is_resumable as appropriate.
      
      One incidental change is to remove a check for generators extending
      classes. This is part of a general check for constructors being the
      only thing which can extend classes, so it is removed here and the
      error message for the general case is made more accurate.
      
      BUG=v8:4483
      
      Review-Url: https://codereview.chromium.org/1996943002
      Cr-Commit-Position: refs/heads/master@{#36621}
      46253e74
  17. 27 May, 2016 1 commit
  18. 18 May, 2016 1 commit
  19. 17 May, 2016 1 commit
  20. 13 May, 2016 2 commits
  21. 18 Apr, 2016 2 commits
  22. 14 Apr, 2016 2 commits
  23. 05 Apr, 2016 2 commits
  24. 01 Apr, 2016 1 commit
  25. 08 Mar, 2016 2 commits
    • verwaest's avatar
      Add GetProperty/GetElement to JSReceiver and use it where possible · 77361020
      verwaest authored
      Also move GetProperty with string-name to JSReceiver
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1775973002
      
      Cr-Commit-Position: refs/heads/master@{#34596}
      77361020
    • 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
  26. 25 Feb, 2016 1 commit
    • jkummerow's avatar
      [runtime] Speed up C++ version of ArrayPush · 2ae50119
      jkummerow authored
      Mostly by avoiding unnecessary Handle/HandleScope creation,
      "length" property lookups, and length conversions.
      This yields about 60% speedup on the microbenchmark I tested with.
      
      Note that the C++ builtin is the middle performance tier of three,
      so not every Array.push use case will be affected by this patch.
      
      Review URL: https://codereview.chromium.org/1716833002
      
      Cr-Commit-Position: refs/heads/master@{#34268}
      2ae50119
  27. 05 Feb, 2016 1 commit
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of... · 3f36e658
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )
      
      Reason for revert:
      Must revert for now due to chromium api natives issues.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > (RELAND: the problem before was a missing write barrier for adding the code
      > entry to the new closure. It's been addressed with a new macro instruction
      > and test. The only change to this CL is the addition of two calls to
      > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      > And Benedikt reviewed it as well.
      >
      > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
      > Cr-Commit-Position: refs/heads/master@{#33741}
      
      TBR=bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1670813005
      
      Cr-Commit-Position: refs/heads/master@{#33766}
      3f36e658
  28. 04 Feb, 2016 1 commit
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · bb31db3a
      mvstanton authored
      (RELAND: the problem before was a missing write barrier for adding the code
      entry to the new closure. It's been addressed with a new macro instruction
      and test. The only change to this CL is the addition of two calls to
      __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      And Benedikt reviewed it as well.
      
      TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1668103002
      
      Cr-Commit-Position: refs/heads/master@{#33741}
      bb31db3a
  29. 29 Jan, 2016 1 commit
    • jkummerow's avatar
      Introduce {FAST,SLOW}_STRING_WRAPPER_ELEMENTS · f4872f74
      jkummerow authored
      String wrappers (new String("foo")) are special objects: their string
      characters are accessed like elements, and they also have an elements
      backing store. This used to require a bunch of explicit checks like:
      
      if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
        /* Handle string characters */
      }
      // Handle regular elements (for string wrappers and other objects)
      obj->GetElementsAccessor()->Whatever(...);
      
      This CL introduces new ElementsKinds for string wrapper objects (one for
      fast elements, one for dictionary elements), which allow folding the
      special-casing into new StringWrapperElementsAccessors.
      
      No observable change in behavior is intended.
      
      Review URL: https://codereview.chromium.org/1612323003
      
      Cr-Commit-Position: refs/heads/master@{#33616}
      f4872f74
  30. 27 Jan, 2016 2 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of... · a7027851
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )
      
      Reason for revert:
      Bug: failing to use write barrier when writing code entry into closure.
      
      Original issue's description:
      > Reland of Type Feedback Vector lives in the closure
      >
      > (Fixed a bug found by nosnap builds.)
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      > BUG=
      >
      > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
      > Cr-Commit-Position: refs/heads/master@{#33548}
      
      TBR=bmeurer@chromium.org,yangguo@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1643533003
      
      Cr-Commit-Position: refs/heads/master@{#33556}
      a7027851
    • mvstanton's avatar
      Reland of Type Feedback Vector lives in the closure · d984b3b0
      mvstanton authored
      (Fixed a bug found by nosnap builds.)
      
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1642613002
      
      Cr-Commit-Position: refs/heads/master@{#33548}
      d984b3b0
  31. 26 Jan, 2016 2 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of... · e2e7dc32
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )
      
      Reason for revert:
      FAilure on win32 bot, need to investigate webkit failures.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
      > Cr-Commit-Position: refs/heads/master@{#33518}
      
      TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1632993003
      
      Cr-Commit-Position: refs/heads/master@{#33520}
      e2e7dc32
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · a5200f7e
      mvstanton authored
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1563213002
      
      Cr-Commit-Position: refs/heads/master@{#33518}
      a5200f7e