Skip to content

V
V8
Switch branch/tag
  1. 26 Sep, 2016 1 commit
    • jgruber's avatar
      Enable component builds for fuzzers · 22606f0c
      jgruber authored 
      V8 is collecting a growing amount of fuzzers, all of which take substantial
space on the bots and in chromium build archives. This CL improves that
situation by allowing component (shared library) builds for almost all fuzzers.

The parser fuzzer is handled as an exception since it would require exporting a
large number of additional functions.

A component build results in about a 50-100x improvement in file size for each
fuzzer (~50M-100M to around 1.1M).

BUG=chromium:648864
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe

Review-Url: https://codereview.chromium.org/2360983002
Cr-Commit-Position: refs/heads/master@{#39709}
      22606f0c
  3. 21 Sep, 2016 3 commits
  5. 20 Sep, 2016 4 commits
  7. 19 Sep, 2016 3 commits
  9. 16 Sep, 2016 2 commits
  11. 12 Sep, 2016 3 commits
  13. 06 Sep, 2016 1 commit
  15. 05 Sep, 2016 1 commit
    • jochen's avatar
      Store the scope info in catch contexts · 9b6ff3a8
      jochen authored 
      Since the extension field is already used for the catch name, store a
ContextExtension there instead.

In the future, this will allow for chaining ScopeInfos together, so we
no longer need a context chain for lazy parsing / compilation.

BUG=v8:5215
R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org

Review-Url: https://codereview.chromium.org/2302013002
Cr-Commit-Position: refs/heads/master@{#39164}
      9b6ff3a8
  17. 01 Sep, 2016 1 commit
  19. 31 Aug, 2016 1 commit
    • neis's avatar
      [modules] Partial scope info support of modules · 840d1e84
      neis authored 
      This introduces a new heap object ModuleInfo, which is to ModuleDescriptor
what ScopeInfo is to Scope.  When deserializing a scope info that contains
a module info, we deserialize the module info into a module descriptor and
put it into the synthesized module scope.

Currently, module infos only store exports.

R=adamk@chromium.org
BUG=v8:1569

Review-Url: https://codereview.chromium.org/2277253003
Cr-Commit-Position: refs/heads/master@{#39049}
      840d1e84
  21. 24 Aug, 2016 1 commit
  23. 18 Aug, 2016 1 commit
    • jgruber's avatar
      Revert of Use a custom Struct for stack trace storage (patchset #4 id:60001 of... · 6b7493a4
      jgruber authored 
      Revert of Use a custom Struct for stack trace storage (patchset #4 id:60001 of https://codereview.chromium.org/2230953002/ )

Reason for revert:
Performance regressions in Gameboy, Life, CodeLoad and others. See crbug.com/638210.

Original issue's description:
> Refactor data structures for simple stack traces
>
> Simple stack traces are captured through Isolate::CaptureSimpleStackTrace.
> Captured frames are stored in a FixedArray, which in turn is stored as a
> property (using a private symbol) on the error object itself. Actual formatting
> of the textual stack trace is done lazily when the user reads the stack
> property of the error object.
>
> This would involve many conversions back and forth between index-encoded raw
> data (receiver, function, offset and code), JS CallSite objects, and C++
> CallSite objects.
>
> This commit refactors the C++ CallSite class into a Struct class called
> StackTraceFrame, which is the new single point of truth frame information.
> Isolate::CaptureSimpleStackTrace stores an array of StackTraceFrames, and JS
> CallSite objects (now created only when the user specifies custom stack trace
> formatting through Error.prepareStackTrace) internally only store a reference
> to a StackTraceFrame.
>
> BUG=
>
> Committed: https://crrev.com/b4c1aefb9c369f1a33a6ca94a5de9b06ea4bf5c4
> Cr-Commit-Position: refs/heads/master@{#38645}

TBR=yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

Review-Url: https://codereview.chromium.org/2252783007
Cr-Commit-Position: refs/heads/master@{#38700}
      6b7493a4
  25. 16 Aug, 2016 1 commit
    • jgruber's avatar
      Refactor data structures for simple stack traces · b4c1aefb
      jgruber authored 
      Simple stack traces are captured through Isolate::CaptureSimpleStackTrace.
Captured frames are stored in a FixedArray, which in turn is stored as a
property (using a private symbol) on the error object itself. Actual formatting
of the textual stack trace is done lazily when the user reads the stack
property of the error object.

This would involve many conversions back and forth between index-encoded raw
data (receiver, function, offset and code), JS CallSite objects, and C++
CallSite objects.

This commit refactors the C++ CallSite class into a Struct class called
StackTraceFrame, which is the new single point of truth frame information.
Isolate::CaptureSimpleStackTrace stores an array of StackTraceFrames, and JS
CallSite objects (now created only when the user specifies custom stack trace
formatting through Error.prepareStackTrace) internally only store a reference
to a StackTraceFrame.

BUG=

Review-Url: https://codereview.chromium.org/2230953002
Cr-Commit-Position: refs/heads/master@{#38645}
      b4c1aefb
  27. 03 Aug, 2016 1 commit
  29. 02 Aug, 2016 1 commit
  31. 01 Aug, 2016 1 commit
  33. 19 Jul, 2016 1 commit
    • bmeurer's avatar
      [stubs] Improve code generation for ToBoolean. · 0abba435
      bmeurer authored 
      Introduce a proper CodeStubAssembler::BranchIfToBooleanIsTrue helper
method, that branches to if_true/if_false labels depending on whether
the value that is passed would yield true or false when fed to
ToBoolean. Use this helper to implement the bytecode handlers w/o having
to materialize the temporary booleans and essentially branching twice.
The CodeStubAssembler::BranchIfToBooleanIsTrue helper favors the most
likely case of a Boolean constant now.

Also migrate the ToBooleanStub to a ToBoolean TurboFan builtin, that
also uses the helper method under the hood.

Remove the now obsolete Oddball::to_boolean field.

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

Review-Url: https://codereview.chromium.org/2151163002
Cr-Commit-Position: refs/heads/master@{#37849}
      0abba435
  35. 18 Jul, 2016 1 commit
  37. 14 Jul, 2016 1 commit
  39. 12 Jul, 2016 1 commit
  41. 07 Jul, 2016 1 commit
  43. 28 Jun, 2016 1 commit
  45. 27 Jun, 2016 2 commits
  47. 24 Jun, 2016 1 commit
  49. 15 Jun, 2016 1 commit
  51. 19 May, 2016 1 commit
  53. 14 May, 2016 1 commit
  55. 06 Apr, 2016 1 commit
    • verwaest's avatar
      Use a dictionary-mode code cache on the map rather than a dual system. · d2eb555e
      verwaest authored 
      The previous code cache system required stubs to be marked with a StubType, causing them to be inserted either into a fixed array or into a dictionary-mode code cache. This could cause names to be in both cases, and lookup would just find the "fast" one first. Given that we clear out the caches on each GC, the memory overhead shouldn't be too bad. Additionally, the dictionary itself should just stay linear for small arrays; that's faster anyway.

This CL additionally deletes some dead IC code.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#35291}
      d2eb555e
  57. 05 Apr, 2016 1 commit