Skip to content

V
V8
Switch branch/tag
  1. 01 Apr, 2016 4 commits
    • jyan's avatar
      S390: Fix '[ic] Use the CallFunction builtin to invoke accessors.' · 9fbc04f8
      jyan authored 
      Fix native compilation error due to gcc error "call of overloaded
‘Operand(int)’ is ambiguous"

R=joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1847303004

Cr-Commit-Position: refs/heads/master@{#35218}
      9fbc04f8
    • jyan's avatar
      S390: [ic] Use the CallFunction builtin to invoke accessors. · 6c38fde9
      jyan authored 
      port 6df9a22c

Original Commit Message:
    The HandlerCompiler did not properly handle the weird edge case when a
    sloppy mode function was installed as an accessor on one of the value
    wrapper prototypes and then accessed via a load from a primitive value.
    In this case we just passed the primitive value untouched instead of
    properly wrapping it first. The CallFunction builtin properly deals with
    all the funny edge cases, so we use it instead of duplicating almost all
    of the logic here (the performance difference is neglible).

R=verwaest@chromium.org, bmeurer@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:599073, v8:4413
LOG=n

Review URL: https://codereview.chromium.org/1849233003

Cr-Commit-Position: refs/heads/master@{#35217}
      6c38fde9
    • mbrandy's avatar
      PPC: [ic] Use the CallFunction builtin to invoke accessors. · 2799cd15
      mbrandy authored 
      Port 6df9a22c

Original commit message:
    The HandlerCompiler did not properly handle the weird edge case when a
    sloppy mode function was installed as an accessor on one of the value
    wrapper prototypes and then accessed via a load from a primitive value.
    In this case we just passed the primitive value untouched instead of
    properly wrapping it first. The CallFunction builtin properly deals with
    all the funny edge cases, so we use it instead of duplicating almost all
    of the logic here (the performance difference is neglible).

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:599073, v8:4413
LOG=n

Review URL: https://codereview.chromium.org/1846953006

Cr-Commit-Position: refs/heads/master@{#35214}
      2799cd15
    • bmeurer's avatar
      [ic] Use the CallFunction builtin to invoke accessors. · 6df9a22c
      bmeurer authored 
      The HandlerCompiler did not properly handle the weird edge case when a
sloppy mode function was installed as an accessor on one of the value
wrapper prototypes and then accessed via a load from a primitive value.
In this case we just passed the primitive value untouched instead of
properly wrapping it first. The CallFunction builtin properly deals with
all the funny edge cases, so we use it instead of duplicating almost all
of the logic here (the performance difference is neglible).

R=verwaest@chromium.org
BUG=chromium:599073, v8:4413
LOG=n

Review URL: https://codereview.chromium.org/1845243005

Cr-Commit-Position: refs/heads/master@{#35187}
      6df9a22c
  3. 30 Mar, 2016 1 commit
  5. 22 Mar, 2016 2 commits
  7. 21 Mar, 2016 3 commits
  9. 18 Mar, 2016 2 commits
  11. 16 Mar, 2016 1 commit
  13. 15 Mar, 2016 3 commits
  15. 10 Mar, 2016 5 commits
    • verwaest's avatar
      Simplify the interface of PropertyCallbackArguments · 3f027300
      verwaest authored 
      Use internal handles as API, and move boilerplate code into the call wrappers.
BUG=

Review URL: https://codereview.chromium.org/1776913005

Cr-Commit-Position: refs/heads/master@{#34684}
      3f027300
    • Toon Verwaest's avatar
      Resort to presubmit style. · 4bbd051a
      Toon Verwaest authored 
      TBR=machenbach@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1777483011 .

Cr-Commit-Position: refs/heads/master@{#34667}
      4bbd051a
    • verwaest's avatar
      Split off api-arguments.[h|cc] from arguments.[h|cc] · 5c73b25f
      verwaest authored 
      NOPRESUBMIT=true
BUG=

Review URL: https://codereview.chromium.org/1776353002

Cr-Commit-Position: refs/heads/master@{#34664}
      5c73b25f
    • verwaest's avatar
      Inline calling into the interceptor into the IC callbacks rather than going... · 79ccf34a
      verwaest authored 
      Inline calling into the interceptor into the IC callbacks rather than going through the LookupIterator.

This is highly performance sensitive as there is no faster path; it's
used directly by the IC.

BUG=chromium:592305
LOG=n

Review URL: https://codereview.chromium.org/1778493005

Cr-Commit-Position: refs/heads/master@{#34660}
      79ccf34a
    • zhengxing.li's avatar
      X87: [runtime] Unify and simplify how frames are marked. · 7a51f8c8
      zhengxing.li authored 
        port 9dcd0857 (r34571)

  original commit message:
  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).

BUG=

Review URL: https://codereview.chromium.org/1774353002

Cr-Commit-Position: refs/heads/master@{#34648}
      7a51f8c8
  17. 09 Mar, 2016 4 commits
    • mbrandy's avatar
      PPC: [runtime] Unify and simplify how frames are marked · 4445c095
      mbrandy authored 
      Port 9dcd0857

Original commit message:
    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).

R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1778713002

Cr-Commit-Position: refs/heads/master@{#34643}
      4445c095
    • vogelheim's avatar
      Rework CallApi*Stubs. · 5096492f
      vogelheim authored 
      - Eliminate stubs with a variable number of arguments.
  (That only worked due to their very limited use. These
   stubs' interface descriptors were basically lying
   about their number of args, which will fail when used
   generically.)
- Fix all CallApi*Stubs' interface descriptors to no
  longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
  FunctionWithFixedArgs.
  (Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
  *ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
  parameters exceeds the supported number of args.

BUG=

Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
Cr-Commit-Position: refs/heads/master@{#34614}

Review URL: https://codereview.chromium.org/1748123003

Cr-Commit-Position: refs/heads/master@{#34627}
      5096492f
    • vogelheim's avatar
      Revert of Rework CallApi*Stubs. (patchset #5 id:100001 of... · 52a741d1
      vogelheim authored 
      Revert of Rework CallApi*Stubs. (patchset #5 id:100001 of https://codereview.chromium.org/1748123003/ )

Reason for revert:
Breaks Chromium.

Original issue's description:
> Rework CallApi*Stubs.
>
> - Eliminate stubs with a variable number of arguments.
>   (That only worked due to their very limited use. These
>    stubs' interface descriptors were basically lying
>    about their number of args, which will fail when used
>    generically.)
> - Fix all CallApi*Stubs' interface descriptors to no
>   longer lie about their arguments.
> - Unify CallApi*Stub, for * in Function, Accessor,
>   FunctionWithFixedArgs.
>   (Since these are now all doing the same thing.)
> - Rename the unified stub (and interface descriptors) to
>   *ApiCallback*, since that's really what they're doing.
> - Refuse inlining an API callback if its number of
>   parameters exceeds the supported number of args.
>
> BUG=
>
> Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
> Cr-Commit-Position: refs/heads/master@{#34614}

TBR=danno@chromium.org,jkummerow@chromium.org,mstarzinger@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/1775933005

Cr-Commit-Position: refs/heads/master@{#34624}
      52a741d1
    • vogelheim's avatar
      Rework CallApi*Stubs. · d238b953
      vogelheim authored 
      - Eliminate stubs with a variable number of arguments.
  (That only worked due to their very limited use. These
   stubs' interface descriptors were basically lying
   about their number of args, which will fail when used
   generically.)
- Fix all CallApi*Stubs' interface descriptors to no
  longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
  FunctionWithFixedArgs.
  (Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
  *ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
  parameters exceeds the supported number of args.

BUG=

Review URL: https://codereview.chromium.org/1748123003

Cr-Commit-Position: refs/heads/master@{#34614}
      d238b953
  19. 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
  21. 07 Mar, 2016 1 commit
  23. 03 Mar, 2016 1 commit
    • bmeurer's avatar
      [runtime] Rename IsUndetectableObject to IsUndetectable. · 0b3e436a
      bmeurer authored 
      This is more consistent with the current naming scheme (i.e. IsCallable
for callable bit on map, IsConstructor for constructor bit on map, and
now IsUndetectable for undetectable bit on map).

Also simplify the fallthrough case for Object::Equals, because we don't
need to check for Null or Undefined or Undetectable, as both Null and
Undefined already have the undetectable bit set on their maps.

R=machenbach@chromium.org

Review URL: https://codereview.chromium.org/1756413003

Cr-Commit-Position: refs/heads/master@{#34458}
      0b3e436a
  25. 01 Mar, 2016 1 commit
  27. 29 Feb, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce a proper ToBooleanStub. · d1df58e8
      bmeurer authored 
      Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
our naming convention, and add a new TurboFan-powered ToBooleanStub,
which just does the ToBoolean conversion without any runtime call or
code patching, so we can use it for Ignition (and TurboFan).

Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
already have for to_string and to_number, so we don't need to actually
dispatch on the concrete Oddball at all.

R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org

Review URL: https://codereview.chromium.org/1744163002

Cr-Commit-Position: refs/heads/master@{#34361}
      d1df58e8
  29. 27 Feb, 2016 1 commit
  31. 26 Feb, 2016 3 commits
    • rmcilroy's avatar
      [Interpreter] Add support for cpu profiler logging. · cb29f9cd
      rmcilroy authored 
      Adds support for cpu profiler logging to the interpreter. Modifies the
the API to be passed AbstractCode objects instead of Code objects, and
adds extra functions to AbstractCode which is required by log.cc and
cpu-profiler.cc.

The main change in sampler.cc is to determine if a stack frame is an
interpreter stack frame, and if so, use the bytecode address as the pc
for that frame. This allows sampling of bytecode functions. This
requires adding support to SafeStackIterator to determine if a frame is
interpreted, which we do by checking the PC against pre-stored addresses
for the start and end of interpreter entry builtins.

Also removes CodeDeleteEvents which are dead code and haven't
been reported for some time.

Still to do is tracking source positions which will be done in a
followup CL.

BUG=v8:4766
LOG=N

Review URL: https://codereview.chromium.org/1728593002

Cr-Commit-Position: refs/heads/master@{#34321}
      cb29f9cd
    • bmeurer's avatar
      [ic] Unify undetectable abstract equality comparison. · 1b821f2f
      bmeurer authored 
      The treatment of different undetectable objects was inconsistent after
the latest changes to the undetectable bit in the maps. Given two
different undetectable JSObjects a and b, a monomorphic CompareIC would
say false for a == b, while the rest of the system (including the
generic case for the CompareIC) would say true.

The fix is rather straight-forward: We just go generic on a CompareIC
once we see an undetectable JSObject.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1735863004

Cr-Commit-Position: refs/heads/master@{#34315}
      1b821f2f
    • adamk's avatar
      Revert of [compiler] Drop the CompareNilIC. (patchset #4 id:60001 of... · fca68bac
      adamk authored 
      Revert of [compiler] Drop the CompareNilIC. (patchset #4 id:60001 of https://codereview.chromium.org/1722193002/ )

Reason for revert:
Speculative revert in attempt to fix #2 crasher on canary.

Original issue's description:
> [compiler] Drop the CompareNilIC.
>
> Since both null and undefined are also marked as undetectable now, we
> can just test that bit instead of having the CompareNilIC try to collect
> feedback to speed up the general case (without the undetectable bit
> being used).
>
> Drive-by-fix: Update the type system to match the new handling of
> undetectable in the runtime.
>
> R=danno@chromium.org
>
> Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba
> Cr-Commit-Position: refs/heads/master@{#34237}

TBR=danno@chromium.org,verwaest@chromium.org,bmeurer@chromium.org
LOG=y
BUG=chromium:589897
NOTRY=true

Review URL: https://codereview.chromium.org/1743433002

Cr-Commit-Position: refs/heads/master@{#34308}
      fca68bac
  33. 24 Feb, 2016 3 commits
    • mythria's avatar
      Revert of [Interpreter] Implements calls through CallICStub in the... · eb358178
      mythria authored 
      Revert of [Interpreter] Implements calls through CallICStub in the interpreter. (patchset #15 id:270001 of https://codereview.chromium.org/1688283003/ )

Reason for revert:
It is not a good idea to call CallICStub from the builtin. It might be sensitive to the frame structure. Constructing a internal frame might cause problems. It is much better to inline the code  related to the type feedback vector into the builtin.

Original issue's description:
> [Interpreter] Implements calls through CallICStub in the interpreter.
>
> Calls are implemented through CallICStub to collect type feedback. Adds
> a new builtin called InterpreterPushArgsAndCallIC that pushes the
> arguments onto stack and calls CallICStub.
>
> Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
> go through CallICStub.
>
> MIPS port contributed by balazs.kilvady.
>
> BUG=v8:4280, v8:4680
> LOG=N
>
> Committed: https://crrev.com/20362a2214c11a0f2ea5141b6a79e09458939cec
> Cr-Commit-Position: refs/heads/master@{#34244}

TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4680

Review URL: https://codereview.chromium.org/1731253003

Cr-Commit-Position: refs/heads/master@{#34252}
      eb358178
    • mythria's avatar
      [Interpreter] Implements calls through CallICStub in the interpreter. · 20362a22
      mythria authored 
      Calls are implemented through CallICStub to collect type feedback. Adds
a new builtin called InterpreterPushArgsAndCallIC that pushes the
arguments onto stack and calls CallICStub.

Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
go through CallICStub.

MIPS port contributed by balazs.kilvady.

BUG=v8:4280, v8:4680
LOG=N

Review URL: https://codereview.chromium.org/1688283003

Cr-Commit-Position: refs/heads/master@{#34244}
      20362a22
    • bmeurer's avatar
      [compiler] Drop the CompareNilIC. · 666aec03
      bmeurer authored 
      Since both null and undefined are also marked as undetectable now, we
can just test that bit instead of having the CompareNilIC try to collect
feedback to speed up the general case (without the undetectable bit
being used).

Drive-by-fix: Update the type system to match the new handling of
undetectable in the runtime.

R=danno@chromium.org

Review URL: https://codereview.chromium.org/1722193002

Cr-Commit-Position: refs/heads/master@{#34237}
      666aec03
  35. 18 Feb, 2016 1 commit
  37. 17 Feb, 2016 1 commit