Skip to content

V
V8
Switch branch/tag
  1. 12 Mar, 2021 1 commit
  3. 24 Nov, 2020 2 commits
  5. 20 Nov, 2020 1 commit
  7. 10 Jun, 2020 1 commit
  9. 23 May, 2019 2 commits
  11. 22 May, 2019 1 commit
  13. 21 May, 2019 1 commit
  15. 15 May, 2019 3 commits
    • Toon Verwaest's avatar
      [json] Don't internalize json string values longer than 10 chars · 123fbb77
      Toon Verwaest authored 
      Internalizing is useful if we expect the string to reoccur many times.
Internalizing too long strings will cost due to hashing, and the resulting
strings will be kept alive for longer. Drop the limit to 10 to be more
conservative.

Change-Id: I2ac2109ca03ab05dbc5c01d4efe6f912b12f65b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611805
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61539}
      123fbb77
    • Toon Verwaest's avatar
      [json] More feedback-guided json parsing · fdde8945
      Toon Verwaest authored 
      Use feedback from adjecent array elements to speed up object creation.

Change-Id: Ib5c1b07cc63afb1a4b0cf194144a0ecd31139cb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612898
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61538}
      fdde8945
    • Toon Verwaest's avatar
      [json] Make json parsing iterative · 4b60b40a
      Toon Verwaest authored 
      This avoids the need to throw range errors when we run out of stack, limiting
us only by available memory.

The main parser loop is implemented by two subloops.

The first subloop finishes whenever it generates primitive values, empty
arrays, or empty objects. If a non-empty object or array is started, the loop
continues to parse its first member.

The second subloop consumes produced values and either adds them to the parent
array or object, or returns it. The second loop finishes whenever a next value
needs to be produced. When the loop itself produces a finished array or object,
the loop continues.

Exceptions are handled by moving the cursor to end-of-input. Upon end-of-input,
the first loop sets the continuation to "kFail". That causes the second loop to
tear down continuation stack and related handle scopes, resulting in an empty
handle.

The CL additionally buffers all named properties and elements so we can
immediately allocate a correctly shaped object. For object elements we'll take
flat array or dictionary encoding depending on what is more efficient.

This means that element handles are now allocated in their parent HandleScope,
rather than having local handlescopes per-property (of big objects); which is
why I've adjusted the handle-count test to not allocate as many properties. In
the future it would be nice to not have to allocate (as many) handles since
almost everything in the JSON graph will survive JSON parsing...

Bug: chromium:710383
Change-Id: Ia3a7fd0ac260fb1c0e5f929276792b2f8e5fc0ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609802Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61533}
      4b60b40a
  17. 06 May, 2019 2 commits
  19. 03 May, 2019 1 commit
    • Sigurd Schneider's avatar
      Revert "Reland "[json] Speed up json parsing"" · 47fccbfd
      Sigurd Schneider authored 
      This reverts commit bbd740f0.

Reason for revert: blocks lkgr due to layout test failure:
https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/31607

Original change's description:
> Reland "[json] Speed up json parsing"
> 
> This is a reland of b0c4a876
> 
> Original change's description:
> > [json] Speed up json parsing
> >
> > - scan using raw data pointers + GC callback
> > - scan using scanner tables
> > - cap internalizing large string values
> > - inline fast transitioning logic
> >
> > Fixes previous CL by moving AllowHeapAllocation to callers of
> > ReportUnexpectedCharacter where needed to make it clear we need to exit.
> >
> > Tbr: ulan@chromium.org
> > Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#61159}
> 
> Tbr: verwaest@chromium.org
> Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
> Change-Id: Ic7d0057178c649fc45b8c8f4587ee9128e351515
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593292
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61179}

TBR=ulan@chromium.org,ishell@google.com,verwaest@google.com,ishell@chromium.org,verwaest@chromium.org

Change-Id: I3ae8f9ce8214bebe7fab9d87c5daf8cdfdb94199
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594438
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61194}
      47fccbfd
  21. 02 May, 2019 3 commits
  23. 30 Apr, 2019 4 commits
  25. 24 Apr, 2019 1 commit
  27. 12 Mar, 2019 1 commit
  29. 01 Mar, 2019 1 commit
  31. 11 Sep, 2018 1 commit
  33. 22 Jun, 2018 1 commit
  35. 30 May, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] use interrupt for pause only as last resort · 6d87d957
      Alexey Kozyatinskiy authored 
      With this CL we use interrupt for pause in two cases:
- when we process Debugger.pause on interruption,
- when we would like to break as soon as possible after OOM.
In all other cases, e.g. for async step into we use break
on function call by calling StepIn debugger action.

In mentioned cases we should not actually use interrupt as well:
- Debugger.pause in this case scheduled using interrupt and we
  may just break right now without requesting another interrupt,
  unfortunately blink side is not ready,
- we should use more reliable way to break right after near OOM
  callback, otherwise we can get this callback, increase limit,
  request break on next interrupt, before interrupt get another
  huge memory allocation and crash.

There are couple advantages:
- we get much better break locations for async stepping
  (see inspector tests expectations),
- we can remove DEBUG_BREAK interruption
  (it should speedup blackboxing with async tasks, see
  removed todo in debug.cc for details)
- it is required preparation step for async step out,
  (see https://chromium-review.googlesource.com/c/v8/v8/+/1054618)

Bug: v8:7753
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iabd7627dbffa9a0eab1736064caf589d02591926
Reviewed-on: https://chromium-review.googlesource.com/1054155
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53439}
      6d87d957
  37. 09 Apr, 2018 2 commits
  39. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored 
      This reverts commit f9a2e24b.

Reason for revert: gc stress failures not all fixed by follow up.

Original change's description:
> [cleanup] Refactor the Factory
> 
> There is no good reason to have the meat of most objects' initialization
> logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
> this CL changes the protocol between Heap and Factory to be AllocateRaw,
> and all object initialization work after (possibly retried) successful
> raw allocation happens in the Factory.
> 
> This saves about 20KB of binary size on x64.
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
> Reviewed-on: https://chromium-review.googlesource.com/959533
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52416}

TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org

Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored 
      There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.

This saves about 20KB of binary size on x64.

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
Reviewed-on: https://chromium-review.googlesource.com/959533
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  41. 09 Mar, 2018 1 commit
  43. 15 Feb, 2018 1 commit
  45. 11 Dec, 2017 1 commit
    • Jeremy Roman's avatar
      Reland: Implement and use VectorSegment to avoid repeated allocation of ZoneVector properties. · d0142857
      Jeremy Roman authored 
      The parser holds a single vector whose backing storage is reused in calls
to ParseJsonObject, so that once we reach the peak number of unstored
properties no more allocations are required.

This improves performance of parsing inputs like those in Speedometer VanillaJS
by about 2% in my local measurement, and would presumably do better on more
pathological inputs.

This should also have the side effect of reducing peak memory usage at this time
slightly, since we do fewer zone allocations which cannot be freed until the
parse finishes.

Reland switches to use std::vector::data instead of operator[] to avoid an index
check in debug MSVC. In such cases the out-of-bounds pointer cannot be
dereferenced, so it is legal.

Bug: chromium:771227
Change-Id: I21837196372c904bfc799cd14353a73d11dcff32
Reviewed-on: https://chromium-review.googlesource.com/804062Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49997}
      d0142857
  47. 30 Nov, 2017 1 commit
  49. 29 Nov, 2017 2 commits
  51. 28 Nov, 2017 1 commit
  53. 03 Nov, 2017 1 commit