Skip to content

V
V8
Switch branch/tag
  1. 09 Apr, 2018 1 commit
  3. 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
  5. 19 Mar, 2018 1 commit
  7. 15 Feb, 2018 1 commit
  9. 20 Dec, 2017 1 commit
  11. 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
  13. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored 
      This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.

Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.

Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters

Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.

BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2
  15. 30 Nov, 2017 1 commit
  17. 29 Nov, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "Implement and use VectorSegment to avoid repeated allocation of ZoneVector properties." · 32033f4f
      Michael Achenbach authored 
      This reverts commit d3104923.

Reason for revert: Breaks win debug, causes lots of timeouts.
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/20387

Original change's description:
> Implement and use VectorSegment to avoid repeated allocation of ZoneVector properties.
> 
> 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.
> 
> Bug: chromium:771227
> Change-Id: I8aa1514b37a74f82539f95f94292c8fa1582d66a
> Reviewed-on: https://chromium-review.googlesource.com/789511
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Jeremy Roman <jbroman@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49693}

TBR=jbroman@chromium.org,marja@chromium.org,cbruni@chromium.org

Change-Id: I5b198aeffed6f1543f6110709dc74b311d4ba144
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:771227
Reviewed-on: https://chromium-review.googlesource.com/796151Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49705}
      32033f4f
  19. 28 Nov, 2017 1 commit
  21. 03 Nov, 2017 1 commit
  23. 25 Oct, 2017 2 commits
  25. 16 Oct, 2017 1 commit
  27. 28 Jul, 2017 1 commit
    • Jakob Kummerow's avatar
      Refactor TransitionArray access · e567dd3a
      Jakob Kummerow authored 
      in preparation for caching StoreIC-Transition handlers in there.
This CL should not change behavior or performance.

The TransitionArray class no longer serves a dual purpose; it is now
simply the data structure serving that role. Further, it now supports
storing transitioning handlers in its "target" slot, which in turn have
a WeakCell pointing to the transition target (but this functionality
is not being used yet).

The interface for accessing a map's transitions, previously implemented
as a set of static functions, is now handled by the TransitionsAccessor
class. It distinguishes the following internal states:
- kPrototypeInfo: map is a prototype map, will never cache any transitions.
- kUninitialized: map can cache transitions, but doesn't have any.
- kWeakCell: map caches a single transition, stored inline. Formerly known
             as "IsSimpleTransition".
- kFullTransitionArray: map uses a TransitionArray to store transitions.
- kTuple3Handler, kFixedArrayHandler: to be used in the future for caching
                                      transitioning handlers.

Change-Id: If2aa68390981f96f317b958445a6e0b935c2a14e
Reviewed-on: https://chromium-review.googlesource.com/550118Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46981}
      e567dd3a
  29. 30 Jun, 2017 1 commit
    • Mathias Bynens's avatar
      [elements] Rename FAST elements kinds · 26c00f4a
      Mathias Bynens authored 
      The `FAST_` prefix doesn’t make much sense — they’re all just different cases
with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.

This patch renames the FAST elements kinds as follows:

- e.g. FAST_ELEMENTS => PACKED_ELEMENTS
- e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS

The following exceptions are left intact, for lack of a better name:

- FAST_SLOPPY_ARGUMENTS_ELEMENTS
- SLOW_SLOPPY_ARGUMENTS_ELEMENTS
- FAST_STRING_WRAPPER_ELEMENTS
- SLOW_STRING_WRAPPER_ELEMENTS

This makes it easier to reason about elements kinds, and less confusing to
explain how they’re used.

R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46361}
      26c00f4a
  31. 07 Jun, 2017 1 commit
  33. 16 May, 2017 1 commit
  35. 28 Apr, 2017 1 commit
  37. 09 Mar, 2017 1 commit
  39. 10 Feb, 2017 1 commit
  41. 23 Jan, 2017 1 commit
  43. 20 Jan, 2017 1 commit
  45. 16 Jan, 2017 1 commit
  47. 10 Jan, 2017 1 commit
  49. 17 Oct, 2016 1 commit
  51. 25 Aug, 2016 1 commit
  53. 14 Jun, 2016 1 commit
  55. 13 Jun, 2016 2 commits
  57. 07 Jun, 2016 1 commit
  59. 06 Jun, 2016 1 commit
  61. 31 May, 2016 1 commit
  63. 23 May, 2016 1 commit
  65. 01 Apr, 2016 1 commit
  67. 01 Mar, 2016 1 commit
  69. 18 Feb, 2016 1 commit
  71. 16 Feb, 2016 2 commits