Skip to content

V
V8
Switch branch/tag
  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
  3. 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
  5. 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
  7. 09 Aug, 2016 1 commit
  9. 01 Aug, 2016 1 commit
  11. 28 Jul, 2016 1 commit
  13. 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
  15. 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
  17. 29 Jun, 2016 3 commits
  19. 28 Jun, 2016 1 commit
  21. 20 Jun, 2016 1 commit
  23. 15 Jun, 2016 1 commit
  25. 14 Jun, 2016 1 commit
  27. 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
  29. 06 Jun, 2016 1 commit
  31. 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
  33. 27 May, 2016 1 commit
  35. 18 May, 2016 1 commit
  37. 17 May, 2016 1 commit
  39. 13 May, 2016 2 commits
  41. 18 Apr, 2016 2 commits
  43. 14 Apr, 2016 2 commits
  45. 05 Apr, 2016 2 commits
  47. 01 Apr, 2016 1 commit
  49. 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
  51. 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
  53. 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
  55. 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
  57. 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
  59. 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
  61. 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