Skip to content

V
V8
Switch branch/tag
  1. 23 Jul, 2015 1 commit
    • danno's avatar
      Unify "runtime-style" IC functions with Runtime intrinsics · bc8041dc
      danno authored 
      Previous to this CL, ICs used a slightly different code idiom
to get to C++ code from generated code than runtime intrinsics,
using an IC_Utility class that in essence provided exactly
the same functionality as Runtime::FunctionForId, but in its
own quirky way.

This CL unifies the two mechanisms, folding IC_Utility
away by making all IC entry points in C++ code, e.g. IC
miss handlers, full-fledged runtime intrinsics. This makes
it possible to eliminate a bunch of ad-hoc declarations and
adapters that the IC system had to needlessly re-invent.

As a bonus and the original reason for this yak-shave:
IC-related C++ runtime functions are now callable from
TurboFan.

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

Cr-Commit-Position: refs/heads/master@{#29811}
      bc8041dc
  3. 13 Jul, 2015 3 commits
  5. 17 Jun, 2015 1 commit
    • jkummerow's avatar
      Clean up JSConstructStub · 882055ff
      jkummerow authored 
      - fix truthfulness of comments
- use InitializeFieldsWithFiller more consistently
- use unsigned comparisons for pointers

No change in functionality intended.

Bonus: improve JavaScriptFrame::Print() for an enhanced debugging experience:

- print PC of each frame
- print the function's source also for optimized frames

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

Cr-Commit-Position: refs/heads/master@{#29082}
      882055ff
  7. 09 Jun, 2015 1 commit
    • mbrandy's avatar
      Fix issues with Arm's use of embedded constant pools · e3d76269
      mbrandy authored 
      - Introduce Assembler::DataAlign for table alignment in code object
- Fix several misuses of r8 (alias of the pool pointer register, pp)
- Fix calculation of pp in OSR/handler entry invocation
- Enable missing cases in deserializer
- Fix references to ool constant pools in comments.

R=rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:497180
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28873}
      e3d76269
  9. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  11. 03 Jun, 2015 1 commit
  13. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029
  15. 26 May, 2015 1 commit
    • erikcorry's avatar
      Move hash code from hidden string to a private symbol · eca5b5d7
      erikcorry authored 
      * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
* In the long run we should do all hidden properties this way and get rid of the
hidden magic 0-length string with the zero hash code.  The advantages include
less complexity and being able to do things from JS in a natural way.
* Initially, the performance of weak set regressed, because it's a little harder
to do the lookup in C++.  Instead of heroics in C++ to make things faster I
moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
* This also changes hash codes of Smis so that they are always Smis.

Performance figures are in the comments to the code review.  Summary: Most of js-perf-test/Collections is neutral.  Set and Map with object keys are 40-50% better.  WeakMap is -5% and WeakSet is +9%.  After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.

In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this.  Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately).  With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.

In a similar vein we could give the magic zero hash code to the hash code
symbol.  Then when we look up the hash code we would sometimes see the table
with all the hidden properties.  This dual use of the field for either the hash
code or the table with all hidden properties and the hash code is rather ugly,
and this CL gets rid of it.  I'd be loath to bring it back.  On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.

One worry is that the benchmark results above are more monomorphic than real
world code, so may be overstating the performance benefits of moving to JS.  I
think this is part of a general issue we have with handling polymorphic code in
JS and any solutions there will benefit this solution, which boils down to
regular property access. Any improvement there will lift all boats.

R=adamk@chromium.org, verwaest@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28622}
      eca5b5d7
  17. 05 May, 2015 2 commits
  19. 21 Apr, 2015 1 commit
  21. 07 Apr, 2015 1 commit
  23. 30 Mar, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Add backend support for float32 operations. · 8dad78cd
      bmeurer authored 
      This adds the basics necessary to support float32 operations in TurboFan.
The actual functionality required to detect safe float32 operations will
be added based on this later. Therefore this does not affect production
code except for some cleanup/refactoring.

In detail, this patchset contains the following features:
- Add support for float32 operations to arm, arm64, ia32 and x64
  backends.
- Add float32 machine operators.
- Add support for float32 constants to simplified lowering.
- Handle float32 representation for phis in simplified lowering.

In addition, contains the following (related) cleanups:
- Fix/unify naming of backend instructions.
- Use AVX comparisons when available.
- Extend ArchOpcodeField to 9 bits (required for arm64).
- Refactor some code duplication in instruction selectors.

BUG=v8:3589
LOG=n
R=dcarney@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27509}
      8dad78cd
  25. 25 Mar, 2015 1 commit
    • mstarzinger's avatar
      Switch full-codegen from StackHandlers to handler table. · 38a719f9
      mstarzinger authored 
      This switches full-codegen to no longer push and pop StackHandler
markers onto the operand stack, but relies on a range-based handler
table instead. We only use StackHandlers in JSEntryStubs to mark the
transition from C to JS code.

Note that this makes deoptimization and OSR from within any try-block
work out of the box, makes the non-exception paths faster and should
overall be neutral on the memory footprint (pros).

On the other hand it makes the exception paths slower and actually
throwing and exception more expensive (cons).

R=yangguo@chromium.org
TEST=cctest/test-run-jsexceptions/DeoptTry

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

Cr-Commit-Position: refs/heads/master@{#27440}
      38a719f9
  27. 19 Mar, 2015 1 commit
  29. 18 Mar, 2015 2 commits
    • mstarzinger's avatar
      Remove kind field from StackHandler. · 15f82138
      mstarzinger authored 
      This relands commit 96f79568.

This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.

There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.

With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27263}
      15f82138
    • hpayer's avatar
      Merge old data and pointer space. · 257ff489
      hpayer authored 
      BUG=

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

Cr-Commit-Position: refs/heads/master@{#27259}
      257ff489
  31. 16 Mar, 2015 2 commits
    • mstarzinger's avatar
      Revert of Remove kind field from StackHandler. (patchset #4 id:60001 of... · 5977ed02
      mstarzinger authored 
      Revert of Remove kind field from StackHandler. (patchset #4 id:60001 of https://codereview.chromium.org/1002203002/)

Reason for revert:
Layout test failure in inspector/sources/debugger/debugger-pause-on-promise-rejection.html

Original issue's description:
> Remove kind field from StackHandler.
>
> This makes the Isolate::Throw logic not depend on a prediction of
> whether an exception is caught or uncaught. Such a prediction is
> inherently undecidable because a finally block can decide between
> consuming or re-throwing an exception depending on arbitray control
> flow.
>
> There still is a conservative prediction mechanism in place that
> components like the debugger or tracing can use for reporting.
>
> With this change we can get rid of the StackHandler::kind field, a
> pre-requisite to do table-based lookups of exception handlers.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/96f79568a926966ebcf0685bf9adc947f4e1fbff
> Cr-Commit-Position: refs/heads/master@{#27210}

TBR=yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#27215}
      5977ed02
    • mstarzinger's avatar
      Remove kind field from StackHandler. · 96f79568
      mstarzinger authored 
      This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.

There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.

With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27210}
      96f79568
  33. 10 Mar, 2015 2 commits
  35. 05 Mar, 2015 1 commit
  37. 03 Mar, 2015 1 commit
  39. 24 Feb, 2015 1 commit
  41. 30 Jan, 2015 1 commit
  43. 28 Jan, 2015 1 commit
  45. 20 Jan, 2015 1 commit
  47. 19 Jan, 2015 1 commit
    • ishell's avatar
      Massive renaming of PropertyType values and other implied stuff. · 33994b4a
      ishell authored 
      PropertyKind:
  DATA -> kData
  ACCESSOR -> kAccessor

PropertyType:
  FIELD -> DATA
  CONSTANT -> DATA_CONSTANT
  ACCESSOR_FIELD -> ACCESSOR
  CALLBACKS -> ACCESSOR_CONSTANT

PropertyLocation:
  IN_OBJECT -> kField
  IN_DESCRIPTOR -> kDescriptor

StoreMode:
  FORCE_IN_OBJECT -> FORCE_FIELD

FieldDescriptor -> DataDescriptor
ConstantDescriptor -> DataConstantDescriptor
CallbacksDescriptor -> AccessorConstantDescriptor

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

Cr-Commit-Position: refs/heads/master@{#26146}
      33994b4a
  49. 16 Jan, 2015 1 commit
  51. 22 Dec, 2014 1 commit
  53. 03 Dec, 2014 1 commit
  55. 02 Dec, 2014 2 commits
  57. 01 Dec, 2014 1 commit
  59. 19 Nov, 2014 1 commit
  61. 14 Oct, 2014 1 commit
  63. 13 Oct, 2014 1 commit
  65. 25 Sep, 2014 1 commit