Skip to content

V
V8
Switch branch/tag
  1. 09 May, 2018 1 commit
  3. 08 May, 2018 1 commit
    • Clemens Hammacher's avatar
      [msan] Add static type checks for non-msan builds · f3745430
      Clemens Hammacher authored 
      Currently, non-msan builds don't check the arguments for
MSAN_ALLOCATED_UNINITIALIZED_MEMORY and MSAN_MEMORY_IS_INITIALIZED
calls, so type errors will only be reported on the msan builder.
This CL adds static_asserts for non-msan builds.

Drive-by: Rename MEMORY_SANITIZER to V8_USE_MEMORY_SANITIZER and move
it to macros.h, where also other such macros (like
V8_USE_ADDRESS_SANITIZER) live.

R=ahaas@chromium.org

Bug: v8:7570
Change-Id: If6c3c6e0d1287b5f1e0c59828cd028d1beac933d
Reviewed-on: https://chromium-review.googlesource.com/1046655Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53071}
      f3745430
  5. 04 May, 2018 1 commit
  7. 03 May, 2018 1 commit
  9. 24 Apr, 2018 1 commit
  11. 18 Apr, 2018 1 commit
  13. 17 Apr, 2018 2 commits
  15. 09 Apr, 2018 1 commit
  17. 06 Apr, 2018 2 commits
  19. 04 Apr, 2018 1 commit
    • Jungshik Shin's avatar
      Reland "Implement a new spec for timezone offset calculation" · 1d3a87bd
      Jungshik Shin authored 
      This is a reland of dbdede01
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .

Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g.  fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
>   https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
>   https://chromium-review.googlesource.com/851265  (a proposed CL to the
>   upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}

Bug: v8:3547, chromium:417640, v8:5714
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
      1d3a87bd
  21. 03 Apr, 2018 3 commits
    • Clemens Hammacher's avatar
      Revert "Implement a new spec for timezone offset calculation" · 965edc0e
      Clemens Hammacher authored 
      This reverts commit dbdede01.

Reason for revert: Fails webkit_tests, blocks roll: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064

Original change's description:
> Implement a new spec for timezone offset calculation
> 
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
> 
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
> 
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
> 
> During a negative transition (e.g.  fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
> 
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
> 
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
> 
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
> 
> This CL used to require one of the two ICU CLs below, but not
> any more.
> 
>   https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
>   https://chromium-review.googlesource.com/851265  (a proposed CL to the
>   upstream ICU).
> 
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}

TBR=adamk@chromium.org,littledan@chromium.org,mlippautz@chromium.org,jshin@chromium.org

Change-Id: I6b3bf4427c761b106280d565a3912cd8e25cf87e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:3547, chromium:417640, v8:5714
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/994192Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52338}
      965edc0e
    • Nico Weber's avatar
      Remove `pragma optimize` from v8. · d8840043
      Nico Weber authored 
      This instance of `pragma optimize` was from long ago when we built with
frame pointers disabled. We always build with frame pointers on these
days.

(Also, clang-cl ignores this pragma and will warn about it.)

Bug: chromium:505314
Change-Id: Ia125c9c54e6ec486247241102de1cb62c72d268b
Reviewed-on: https://chromium-review.googlesource.com/993423
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52336}
      d8840043
    • Jungshik Shin's avatar
      Implement a new spec for timezone offset calculation · dbdede01
      Jungshik Shin authored 
      https://github.com/tc39/ecma262/pull/778 was recently merged
to Ecma 262.

It changes the way to convert between "local time" and UTC in such
a way that it'd work for all timezones whether or not there has
been any change in the timezone offset of the standard time. For
instance, Europe/Moscow and some parts of US state of Indiana have
changed the standard (non-DST) timezone offset a few times. The
previous spec assumes that the the standard timezone offset is
constant, but the new spec take into account the offset change
history.

In addition, it specifies a new way to calculate the timezone
offset during a timezone transition (either in and
out of DST or timezone offset shift).

During a negative transition (e.g.  fall backward / getting
out of DST), repeated times are to be interpreted as if the
offset before the transition is in effect.

During a positive transition (e.g. spring forward / getting
into DST), skipped times are to be treated similarly. That
is, they are to be interpreted as if the offset before the
transition is in effect.

With icu-timezone-data, v8 is compliant to the new spec for the
past and the future as well as now whether or not the standard
timezone offset of a given timezone has changed over time
(e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
Australia/Lord_Howe (30 minute DST change) also works per spec.

Without icu-timezone-data, it works only for timezones of which
the standard timezone offset is the same as the current offset
(e.g. most North American timezones other than parts of Indiana)
and of which the DST shift is an hour. For instance, it doesn't work
for Europe/Moscow in 2010 when the standard timezone offset was
+4h because the current (2018) standard timezone offset is +3h. Neither
does it for Lord Howe in Australia with the DST shift of 0.5 hr.

This CL used to require one of the two ICU CLs below, but not
any more.

  https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
  https://chromium-review.googlesource.com/851265  (a proposed CL to the
  upstream ICU).

Bug: v8:3547,chromium:417640,v8:5714
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
Reviewed-on: https://chromium-review.googlesource.com/572148
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: 's avatarDaniel Ehrenberg <littledan@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52332}
      dbdede01
  23. 30 Mar, 2018 1 commit
  25. 23 Mar, 2018 1 commit
  27. 22 Mar, 2018 1 commit
  29. 20 Mar, 2018 1 commit
  31. 19 Mar, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Call FatalProcessOutOfMemory on OOM · 468a9303
      Clemens Hammacher authored 
      Instead of returning nullptr, just always call FatalProcessOutOfMemory
when we cannot allocate more memory.
In a follow-up CL, this should be extended to first try to run a GC and
see if this freed enough memory.
This CL is intentionally minimal in order to make it backmergable.

The unittest for WasmCodeManager needs to be refactored into a
parameterized test, such that each individual (parameterized) test can
die with OOM without affecting other tests.

R=mstarzinger@chromium.org

Bug: chromium:822266
Change-Id: I1336aa05ed50124b77ffaa4435ec9bed70e15c18
Reviewed-on: https://chromium-review.googlesource.com/966501Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52025}
      468a9303
  33. 02 Mar, 2018 1 commit
  35. 01 Mar, 2018 1 commit
    • Clemens Hammacher's avatar
      Fix is_trivially_copyable check for MSVC and older stdlibc++ · 9dd6f0d0
      Clemens Hammacher authored 
      MSVC 2015 and 2017 implement std::is_trivially_copyable, but not
correctly. Hence, reimplement it using more low-level primitives.

For stdlibc++ versions below 5.0, we already have a workaround for the
missing support of std::is_trivially_copyable, but this is an unsound
approximation, because it is ignoring move constructor, move assignment
and copy assignment. Therefore, do not use this approximation for
asserting trivial copyability of a type.

Finally, add unittests for the new is_trivially_copyable
implementations.

R=mstarzinger@chromium.org
CC=loorongjie@gmail.com

Change-Id: I9ee56a65882e8c94b72c9a2d484edd27963a5d89
Reviewed-on: https://chromium-review.googlesource.com/941521Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51651}
      9dd6f0d0
  37. 28 Feb, 2018 1 commit
    • Nico Weber's avatar
      Make v8 build with -Wmicrosoft-cast under clang-cl. · 58b386c4
      Nico Weber authored 
      gcc and clang (and the standard) don't allow implicit conversion of
function pointers to object pointers. MSVC does allow that, and since
system headers require this to work, clang-cl allows it too -- but
it emits a -Wmicrosoft-cast warning (which we currently suppress in
the Chromium build, but which we want to enable.)

As a side effect, when printing a function pointer to a stream, MSVC
(and clang-cl) will pick the operator<<(void*) overload, while gcc
and clang will pick operator<<(bool) since the best allowed conversion
they find is from function pointer to bool.

To prevent the clang-cl warning, we need to make sure that we never
directly print a function pointer to a stream. In v8, this requires
two changes:

1. Give PrintCheckOperand() an explicit specialization for function
   pointers and explicitly cast to void* there.  This ports
   https://codereview.chromium.org/2515283002/ to V8, and also fixes a
   bug on non-Windows where DCHECK() of function pointers would print
   "(1 vs 1)" instead of the function's addresses.
   (The bug remains with member function pointers,
   where it's not clear what to print instead of the 1.)

2. has_output_operator<T> must not use operator<< on its argument
   in an evaluated context if T is a function pointer.  This patch
   modifies has_output_operator<> to use an unevaluated context instead,
   which is simpler than the current approach (and matches what Chromium's
   base does), but changes behavior    in minor (boring) ways
   (see template-utils-unittest.cc), since operator<<() is now
   called with a temporary and only operator<<() implementations callable
   with a temporary are considered.
   A more complicated but behavior-preserving alternative would be to
   add an explicit specialization for function pointers. You can see
   this variant in patch set 1 on gerrit.

Bug: chromium:550065
Change-Id: Idc2854d6c258b7fc0b959604006d8952a79eca3d
Reviewed-on: https://chromium-review.googlesource.com/940004
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51636}
      58b386c4
  39. 26 Feb, 2018 1 commit
  41. 20 Feb, 2018 1 commit
  43. 16 Feb, 2018 1 commit
  45. 14 Feb, 2018 1 commit
  47. 13 Feb, 2018 1 commit
  49. 08 Feb, 2018 1 commit
  51. 06 Feb, 2018 2 commits
  53. 02 Feb, 2018 3 commits
  55. 01 Feb, 2018 1 commit
    • Gabriel Charette's avatar
      Make TimeTicks::Now() high-resolution whenever possible with low-latency. · 954146a5
      Gabriel Charette authored 
      It was already always high-resolution on POSIX but was never high
resolution on Windows. Windows does support low latency high-resolution
timers for the majority of our user base.

TimeTicks::HighResolutionNow() was only explicitly requested in testing
frameworks. As such I left the call in place but made it DCHECK that
it's running on a Windows machine on which high-resolution clocks are
used. This confirms that none of our test fleet has regressed with this
change (the previous HighResolutionNow() used to be slightly more
aggressive and also do it in a few configurations where we now fallback
to low-resolution now).

This implementation was copied as-is (modulo minor v8 API
compatibility tweaks). These implementations were the same in the
past but had diverged when, sadly, the same bug was fixed separately
years apart, in Chromium and V8:
chromium: https://codereview.chromium.org/1284053004 + https://codereview.chromium.org/2393953003
v8: https://codereview.chromium.org/1304873011

This is a prerequisite to add metrics around parallel task execution
(low-resolution clocks are useless at that level, but we also don't want
to incur high-latency clocks on machines that can't afford it cheaply).

Bug: chromium:807606
Change-Id: Id18e7be895d8431ebd0e565a1bdf358fe7838489
Reviewed-on: https://chromium-review.googlesource.com/897485Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51027}
      954146a5
  57. 31 Jan, 2018 2 commits
  59. 24 Jan, 2018 1 commit
    • Michael Starzinger's avatar
      Revert "[platform] Remove {PageAllocator::kReadWriteExecute}." · db7bdf48
      Michael Starzinger authored 
      This reverts commit bf19e60c.

Reason for revert: Two issues discovered with W^X in V8's 6.5 branch (see v8:7272 and chromium:793428). Still need a way to disable the feature.

Original change's description:
> [platform] Remove {PageAllocator::kReadWriteExecute}.
> 
> Now that write-protection of code memory is enabled everywhere and V8 is
> fully W^X compliant, we can remove the permission mode in question.
> 
> R=​hpayer@chromium.org
> BUG=v8:6792
> 
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I80fe95ac6bb0e2d1ad6d993154ce45d492d941be
> Reviewed-on: https://chromium-review.googlesource.com/866855
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50770}

TBR=bbudge@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:6792
Change-Id: If4a205497ac83084a4092560363affb13b391462
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/883461Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50834}
      db7bdf48
  61. 22 Jan, 2018 1 commit
  63. 19 Jan, 2018 1 commit