Skip to content

V
V8
Switch branch/tag
  1. 31 Jan, 2018 12 commits
  3. 30 Jan, 2018 19 commits
  5. 29 Jan, 2018 9 commits
    • Jungshik Shin's avatar
      Block ICU data override with loading from file · f5933218
      Jungshik Shin authored 
      This is a v8-port of
https://chromium-review.googlesource.com/c/chromium/src/+/890176 .

By default, ICU tries to load data items (e.g. brkitr/char.brk)
from individual files before trying the common data. Because
all the ICU data Chrome needs is included in the common ICU data file
that is memory mapped in InitializeICU(), trying to load from the
disk just wastes cycles because there's no file with separate ICU data
items.

Bug: chromium:805694
Test: Intl tests
Change-Id: Ia7e77d658b56d98027336acd2c91fd5f7b2cea3e
Reviewed-on: https://chromium-review.googlesource.com/890343Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50939}
      f5933218
    • Junliang Yan's avatar
      Fix GCC 5.4 error on ubuntu 16.04 · 7dccb798
      Junliang Yan authored 
      The stock GCC on Ubuntu 16.04 complains these constants
are unused (possibly gcc issue). This CL changes these
to constexpr to workaround gcc errors.

R=clemensh@chromium.org, joransiu@ca.ibm.com

Change-Id: I8c1772e91744bc46ace6bee576b90d40c0cdf41f
Reviewed-on: https://chromium-review.googlesource.com/881554Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#50936}
      7dccb798
    • Sathya Gunasekaran's avatar
      [class] Implement private fields runtime semantics · 2c5de06c
      Sathya Gunasekaran authored 
      Things that don't work yet:
(a) pre parsed scope data is broken
(b) private fields can be accessed outside classes
(c) no early or runtime error for accessing unknown fields

Things that do work:
everything else

Change-Id: I3d58be44e2be73ec50defb42403112a8a5e68c54
Bug: v8:5368
Reviewed-on: https://chromium-review.googlesource.com/865497
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50935}
      2c5de06c
    • Benedikt Meurer's avatar
      [builtins] Refactor the Microtask pumping to CSA-only. · c8da060b
      Benedikt Meurer authored 
      This adjusts the RunMicrotask logic to invoke CallHandlerInfo microtasks
from CSA land directly (via a runtime function call), instead of bailing
out to C++ for the rest of the microtask queue entries. Even in simple
micro-benchmarks there doesn't seem to be a huge performance difference.
In fact performance get's better when CallHandlerInfo and promises are
mixed, which makes sense, since calling from C++ to JS land is more
expensive than the other way around.

But just in case the runtime function call overhead ever becomes the
bottleneck we can introduce a direct C++ call and setup a handle scope
around it, much like a very simple version of CallApiFunctionStub.

This greatly simplifies the microtask handling and paves the way for
refactoring the queue to significant reduce the GC overhead associated
with promises currently.

Bug: v8:7253
Change-Id: I33adb62a6bada138674d324f36d4be894e27f3c9
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/890441Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50934}
      c8da060b
    • Benedikt Meurer's avatar
      [builtins] Use @@species protector for the PromiseResolve fast-path. · 9a6c54fc
      Benedikt Meurer authored 
      The @@species protector guards the following (in case of Promises):

  - The initial Promise.prototype has the initial "constructor"
    pointing to the Promise constructor.
  - No JSPromise instance has a "constructor" property.

So this is sufficient to guard the fast-path in PromiseResolve, given
that we check whether the value is actually a JSPromise and that the
[[Prototype]] of value is the (initial) Promise.prototype.

Also refactor the code a bit and avoid the BranchIfSameValue, which
blows up the builtin quite a lot, since we already know that constructor
must be a valid JSReceiver and thus we can simply use WordEqual to
compare value's "constructor" to the constructor.

Bug: v8:7253
Change-Id: I6413882241c9648c95bb2299100a6c3a7c803110
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/890438Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50933}
      9a6c54fc
    • Ali Ijaz Sheikh's avatar
      [heap] do not perform a step while a space is partially mutated · 70c02375
      Ali Ijaz Sheikh authored 
      We were starting an allocation step during NewSpace::AddFreshPage. At
this point, we had advanced the page, but not updated allocation_info_.
This ultimately led to assertions as Space::Size was not expecting
to be called when to_space_.page_{high,low} are inconsistent with
allocation_info_.top().

The solution here is to avoid starting the step in the middle of the
space state mutation. We account for memory allocated so far before the
mutation is started, and then start a new step after the mutation has
been completed.

Bug: chromium:806179
Change-Id: I17ee896d80c4ec752baa2b17c3fd2bef7ea2ca33
Reviewed-on: https://chromium-review.googlesource.com/889981Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#50932}
      70c02375
    • Clemens Hammacher's avatar
      [simulator] Make SimulatorBase::VariadicCall protected · 74915b73
      Clemens Hammacher authored 
      Even though most compilers accept the method to be private, gcc 4.8
complains about this (which seems to be correct). Thus we make this
method protected.

R=franzih@chromium.org

Change-Id: Ia49b2ddebe1ced7529d4943107a76a909c355b73
Reviewed-on: https://chromium-review.googlesource.com/890449Reviewed-by: 's avatarFranziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50931}
      74915b73
    • Michael Achenbach's avatar
      [test] Add interrupt-budget fuzzer · dc210a95
      Michael Achenbach authored 
      This adds back an option for interrupt budget available in no-snap
builds. This also adds a fuzzer configuration for numfuzz that enables
fuzzing the interrupt budget option. A new flag --disable-analysis
allows to generally skip the fuzzer's analysis phase, which can be
chosen for interrupt budget, which doesn't support an analysis phase.

Bug: v8:6917
Change-Id: I546dd9ee41c3e0fb027108ef4606a34514f230d4
Reviewed-on: https://chromium-review.googlesource.com/885805Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50929}
      dc210a95
    • Gabriel Charette's avatar
      Revert "v8::ItemParallelJob : Do not launch more Tasks than there are Items to process." · 2407b2bd
      Gabriel Charette authored 
      This reverts commit 8a27c7d3.

Reason for revert: 

Having more tasks then work items is intentional in some use cases, i.e. Scavenging where RunInParallel() does parallel processing on a dynamic workload *after* the initial set of work items:

    {
      barrier_->Start();
      TimedScope scope(&scavenging_time);
      PageScavengingItem* item = nullptr;
      while ((item = GetItem<PageScavengingItem>()) != nullptr) {
        item->Process(scavenger_);
        item->MarkFinished();
      }
      do {
        scavenger_->Process(barrier_);
      } while (!barrier_->Wait());
      scavenger_->Process();
    }

Original change's description:
> v8::ItemParallelJob : Do not launch more Tasks than there are Items to process.
> 
> Except when there are 0 items. For some reason I don't quite understand yet, not
> calling Run() on tasks_[0] when there are 0 items results in DCHECKs...
> 
> Bug: chromium:806237
> Change-Id: I38c8fffde64a42f93f4efda492832651137eebd7
> Reviewed-on: https://chromium-review.googlesource.com/888704
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50924}

TBR=gab@chromium.org,mlippautz@chromium.org

Change-Id: Iad2ab16bb41f339de8e3fbca1c08c5d26b8a0111
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:806237
Reviewed-on: https://chromium-review.googlesource.com/891186Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50928}
      2407b2bd