Skip to content

V
V8
Switch branch/tag
  1. 25 Oct, 2018 1 commit
  3. 24 Oct, 2018 1 commit
  5. 23 Oct, 2018 2 commits
  7. 22 Oct, 2018 1 commit
  9. 18 Oct, 2018 1 commit
  11. 12 Oct, 2018 1 commit
  13. 01 Oct, 2018 1 commit
  15. 26 Sep, 2018 1 commit
  17. 19 Sep, 2018 1 commit
    • Clemens Hammacher's avatar
      [base] Remove OffsetFrom and AddressFrom · 60d6f7c2
      Clemens Hammacher authored 
      Those two methods are spread over the code base, and their purpose is
often not clear. Historically, they were used to turn pointers into
integers in order to do computations on them. Today we have {Address}
which is uintptr_t, so we can compute directly on that.

This also makes the {RoundUp} and {RoundDown} macros only work on
integral values (including {Address}).

R=mlippautz@chromium.org

Bug: v8:8015
Change-Id: Ia98fb826793ee5d3a2a5b18c09c329d088443772
Reviewed-on: https://chromium-review.googlesource.com/1233914Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56048}
      60d6f7c2
  19. 14 Sep, 2018 1 commit
  21. 13 Sep, 2018 2 commits
  23. 05 Sep, 2018 1 commit
  25. 31 Aug, 2018 1 commit
  27. 30 Aug, 2018 1 commit
  29. 28 Aug, 2018 1 commit
  31. 23 Aug, 2018 1 commit
    • Bruce Dawson's avatar
      Use PAGE_TARGETS_INVALID when allocating code pages · 6930df0f
      Bruce Dawson authored 
      PAGE_TARGETS_INVALID tells CFG (Control Flow Guard) to mark all
addresses as invalid indirect branch targets. This makes exploits more
difficult. The benefit is minor because most of the code in the Chrome
process doesn't use the CFG checks, but this will close off a few
weaknesses and is the direction we will want to go in eventually
anyway (with specific targets or call sites opted-in to allowing
calls, using SetProcessValidCallTargets).

PAGE_TARGETS_INVALID may ultimately cause CFG to not allocate memory -
that is implied by Windows Internals 7th Edition - and if that is
implemented then this change will save some modest amount of memory.

PAGE_TARGETS_INVALID was introduced in Windows 10 - according to
Windows Internals Part 1 7th Edition - prior to that it will cause
VirtualAlloc to fail.

Bug: chromium:870054
Change-Id: Ib1784fba37cc0ecb5fe5df595f1519531b3b3a20
Reviewed-on: https://chromium-review.googlesource.com/1186025
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55365}
      6930df0f
  33. 23 Jul, 2018 1 commit
  35. 12 Jul, 2018 1 commit
  37. 22 Jun, 2018 1 commit
  39. 06 Jun, 2018 1 commit
  41. 16 May, 2018 1 commit
    • Dan Elphick's avatar
      [heap] Start making ReadOnlySpace Pages relocatable · 7485b129
      Dan Elphick authored 
      Adds Page::MakeHeaderRelocatable that clears pointers to objects
outside the space. In this case relocatable means the entire page
heading is position independent in memory, meaning it could be saved to
disk and reloaded at a different memory location in a new process
without there being any invalid pointers.

Currently this only affects mutex_, locate_tracker_ and reservation_.

Additionally makes VerifyHeap work when there's no mutex in a Page.

This is just a stepping stone to making the Pages headers relocatable
since heap_ and owner_ still point out of the Page.

Also removes the empty ReadOnlySpace destructor.

Bug: v8:7464
Change-Id: Ife3c06575fa73a5818c4991fb9bec30a5f43901d
Reviewed-on: https://chromium-review.googlesource.com/1054879Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53196}
      7485b129
  43. 18 Apr, 2018 1 commit
  45. 17 Apr, 2018 1 commit
  47. 06 Apr, 2018 2 commits
  49. 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
  51. 03 Apr, 2018 2 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
    • 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
  53. 30 Mar, 2018 1 commit
  55. 23 Mar, 2018 1 commit
  57. 22 Mar, 2018 1 commit
  59. 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
  61. 26 Feb, 2018 1 commit
  63. 20 Feb, 2018 1 commit
  65. 13 Feb, 2018 1 commit
  67. 06 Feb, 2018 2 commits
  69. 02 Feb, 2018 1 commit
    • Gabriel Charette's avatar
      Bring Time(Delta)::Min/Max() and related helpers to V8. · db73d446
      Gabriel Charette authored 
      Copied as-is modulo compile tweaks from Chromium's base.

Copied tests highlighting existing overflow issues with V8's impl...

TimeDelta::Max() will initially be used in V8 to flag events that
never triggered in a TimedHistogram.

Also constexpr'ed a few things while I was in there, it's harmless
at worst and helps a little at best.
Ideally would constexpr all the Time*::From*() methods like in
Chromium but that has inlining implications and I don't know the
impact that could have on V8.

Bug: chromium:807606
Change-Id: If5aa92759d985be070e12af4dd20f0159169048b
Reviewed-on: https://chromium-review.googlesource.com/899342Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51073}
      db73d446