Skip to content

V
V8
Switch branch/tag
  1. 06 Dec, 2021 1 commit
  3. 04 Dec, 2021 1 commit
    • Samuel Groß's avatar
      Introduce VirtualAddressSpace interface · a7cb30b0
      Samuel Groß authored 
      This interface is meant to eventually replace the existing
v8::PageAllocator interface. Beyond general refactoring of the
PageAllocator APIs, the new interface now supports the concept of
(contiguous) address space reservations, which previously had to be
implemented through page allocations. These reservations now make better
use of provided OS primitives on Fuchsia (VMARs) and Windows
(placeholder mappings) and can be used to back many of the cages and
virtual memory regions that V8 creates.

The new interface is not yet stable and may change at any time without
deprecating the old version first.

Bug: chromium:1218005
Change-Id: I295253c42e04cf311393c5dab9f8c06bd7451ce3
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301475
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78235}
      a7cb30b0
  5. 30 Nov, 2021 4 commits
  7. 25 Nov, 2021 1 commit
  9. 22 Nov, 2021 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Support multiple clients in shared GC" · 2c88cec4
      Dominik Inführ authored 
      This is a reland of 90a9d6cb

The original CL got reverted because of two different issues:

* The DCHECK failure on AllowGarbageCollection::IsAllowed() got fixed
  in https://crrev.com/c/3289625.
* The crash with the incremental marking job were because of a nested
  GC started from a SafepointScope. This CL adds IgnoreLocalGCRequests
  scopes to SafepointScopes in src/heap.

In addition this CL prevents shared GCs during isolate deserialization
by locking the clients_mutex_ until the isolate is fully deserialized.
The original GC used a DisallowSafepoints scope to prevent shared GCs
from interrupting isolate deserialization.

Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}

Bug: v8:11708, v8:12375, v8:12377
Change-Id: I9d1af6fbc06a3a8b6f216ec5e9027665ad071809
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283067
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78013}
      2c88cec4
  11. 20 Nov, 2021 1 commit
  13. 15 Nov, 2021 3 commits
  15. 11 Nov, 2021 1 commit
    • Dominik Inführ's avatar
      Revert "[heap] Support multiple clients in shared GC" · 2f98fb28
      Dominik Inführ authored 
      This reverts commit 90a9d6cb.

Reason for revert: Seems to make some test to fail flakily. Revert for now until this is fixed.

Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}

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

Bug: v8:11708
Change-Id: I85fbf896c59492fc571b3bfaa7f9e3ea8a883260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275552
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77845}
      2f98fb28
  17. 10 Nov, 2021 1 commit
    • Dominik Inführ's avatar
      [heap] Support multiple clients in shared GC · 90a9d6cb
      Dominik Inführ authored 
      Add support for safepointing multiple isolates as described in the
design doc (link is below). A safepoint across multiple isolates is
considered a global safepoint to distinguish it from regular safepoints.

The basic idea behind the implementation is that we reach a
safepoint for each client. What's new is that now also main threads
need to participate in the safepointing protocol and need to give up
control in time. The slow paths of Park(), Unpark() and Safepoint() on
the main thread need to be adjusted for this reason as well.

This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
IsolateSafepoint and IsolateSafepointScope.

This CL adds the type IgnoreLocalGCRequests, it is used to prevent
Park() and Unpark() from honoring the request from background threads
to perform a local GC. This is used heap-internally to not have GCs
(or even nested GCs) in certain locations. E.g. when initiating a
safepoint to perform a GC we don't want a "recursive" GC to occur.

Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing

Bug: v8:11708
Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77812}
      90a9d6cb
  19. 05 Nov, 2021 1 commit
  21. 25 Oct, 2021 1 commit
  23. 19 Oct, 2021 1 commit
  25. 15 Oct, 2021 1 commit
  27. 14 Oct, 2021 2 commits
    • Samuel Groß's avatar
      Add special handling for Windows in DetermineAddressSpaceLimit · 72cd8c1a
      Samuel Groß authored 
      On Windows pre 8.1, userspace is limited to 8TB of virtual address
space. Take that into account when determining the size and/or placement
of the virtual memory cage.

Bug: chromium:1218005
Change-Id: Idda94534cad67dc2db77e9ba459e3a4b239dac2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222763Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77402}
      72cd8c1a
    • Samuel Groß's avatar
      Implement DetermineAddressSpaceLimit() on x64 · 571eca5c
      Samuel Groß authored 
      This function tries to determine the number of virtual address bits
available on the current CPU and with that the maximum size of the
userspace address space. On x64, it can be implemented through CPUID.

The result of this function is now used in two ways: first, it limits
the maximum size of the virtual memory cage, currently to a quarter of
the address space. Second, it influences the placement of fake cages,
which are attempted to be placed into the lower half of the address
space so that they are followed by large amounts of (hopefully) unused
but addressable virtual memory in which pages can be allocated.

Bug: chromium:1218005
Change-Id: I0edc5d241d899f16dbc47492fa1534b6aaa4aa13
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220348
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77393}
      571eca5c
  29. 13 Oct, 2021 2 commits
    • Samuel Groß's avatar
      Reland "Implement a fake virtual memory cage mechanism" · 0aaec6ed
      Samuel Groß authored 
      This is a reland of 1ea76c13

Disabled the failing test on Fuchsia until its PageAllocator
respects allocation hints.

Original change's description:
> Implement a fake virtual memory cage mechanism
>
> On operating systems where reserving virtual address space is expensive,
> notably Windows pre 8.1, it is not possible to create a proper virtual
> memory cage. In order to still be able to reference caged objects
> through offsets from the cage base on these systems, this CL introduces
> a fake cage mechanism. When the fake cage is used, most of the virtual
> memory for the cage is not actually reserved. Instead, the cage's page
> allocator simply relies on hints to the OS to obtain pages inside the
> cage. This does, however, not provide the same security benefits as a
> real cage as unrelated allocations might end up inside the cage.
>
> Bug: chromium:1218005
> Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
> Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217200
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77367}

Bug: chromium:1218005
Change-Id: I2ed95d121db164679c38085115e8fa92690c057e
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220151Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77378}
      0aaec6ed
    • Camillo Bruni's avatar
      Reland "[flags] Skip --random-seed in FlagList::Hash" · b704bc09
      Camillo Bruni authored 
      This is a reland of 9fe53c4f

- Fix data-race by using an atomic for flag_hash;
- Make sure flag_hash != 0
- Initialize flag_hash in V8::InitializeOncePerProcessImpl
- Clear flag_hash in more cases

Original change's description:
> [flags] Skip --random-seed in FlagList::Hash
>
> Node and friends use --random-seed to temporary reset the seed for
> predictable code-cache creation. To allow custom random seeds at runtime
> the flag is reset for encoding the FlagList::Hash in the snapshots.
>
> We will soon disallow changing flags via the API after V8 has been
> initialized. In order to make node work we will exclude --random-seed
> from the FlagList::Hash calculation.
>
> Drive-by-fix:
> * Lazily initialize flag_hash instead of calculating it after every call
>   to SetFlagsFromString / EnforceFlagImplications.
> * Simplify hash string source creation since out << flag now includes
>   the full flag information
>
> Bug: v8:12309
> Change-Id: I1a168f4702d8c4d160ff12fdbea881731e4ea8b6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218159
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77345}

Bug: v8:12309
Change-Id: I12cd2931d81dc74e07a4da3564e4bf8dd151300a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218981
Commit-Queue: Marja Hölttä <marja@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77373}
      b704bc09
  31. 12 Oct, 2021 2 commits
    • Deepti Gandluri's avatar
      Revert "Implement a fake virtual memory cage mechanism" · 1a0b993d
      Deepti Gandluri authored 
      This reverts commit 1ea76c13.

Reason for revert: The unit test added fails on the Fuchsia bot https://ci.chromium.org/p/v8/builders/ci/V8%20Fuchsia/25976?

Original change's description:
> Implement a fake virtual memory cage mechanism
>
> On operating systems where reserving virtual address space is expensive,
> notably Windows pre 8.1, it is not possible to create a proper virtual
> memory cage. In order to still be able to reference caged objects
> through offsets from the cage base on these systems, this CL introduces
> a fake cage mechanism. When the fake cage is used, most of the virtual
> memory for the cage is not actually reserved. Instead, the cage's page
> allocator simply relies on hints to the OS to obtain pages inside the
> cage. This does, however, not provide the same security benefits as a
> real cage as unrelated allocations might end up inside the cage.
>
> Bug: chromium:1218005
> Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
> Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217200
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77367}

Bug: chromium:1218005
Change-Id: I541bb9656ab2a6a080c2a30d372226fcc5c95391
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219086
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77368}
      1a0b993d
    • Samuel Groß's avatar
      Implement a fake virtual memory cage mechanism · 1ea76c13
      Samuel Groß authored 
      On operating systems where reserving virtual address space is expensive,
notably Windows pre 8.1, it is not possible to create a proper virtual
memory cage. In order to still be able to reference caged objects
through offsets from the cage base on these systems, this CL introduces
a fake cage mechanism. When the fake cage is used, most of the virtual
memory for the cage is not actually reserved. Instead, the cage's page
allocator simply relies on hints to the OS to obtain pages inside the
cage. This does, however, not provide the same security benefits as a
real cage as unrelated allocations might end up inside the cage.

Bug: chromium:1218005
Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217200
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77367}
      1ea76c13
  33. 08 Oct, 2021 2 commits
  35. 07 Oct, 2021 2 commits
    • Frank Tang's avatar
      Reland "[intl] Fix consistency in Intl API" · fed33f90
      Frank Tang authored 
      This is a reland of a1e6efd8

Fix Android issue by checking the resources is not filtering out.

Original change's description:
> [intl] Fix consistency in Intl API
>
> Fix several edge cases consistency issues with ICU discovered by test262 test by
> using Intl Enumeration API
> 1. Work around ICU short coming of always fallback in currency display
>  name so when the fallback is "none" in DisplayNames, the force fallback
> code will produce the correct undefined from the of(currency_code) method.
> 2. Always check numbering system is not algorithm based numbering system
> to fix DateTimeFormat/RelativeTimeFormat/NumberFormat
> resolvedOptions().numberingSystem when the reqested numberingSystem is one
> of the numbering systems that we filter out the resources and not supported.
> 3. Generalize the iso8601 bit solution in DateTimeFormat and rename it to
> alt_calendar bit to also fix DateTimeFormat resolvedOptions report
> calendar as "islamic" while requesting "islamic-rgsa".
> 4. Work around reporting inconsistency of currency code and display name
> in ICU.
>
> Bug: v8:12209
> Change-Id: Ibd349ee55426fad7d6f20a5e93fb35ff7438e111
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3153576
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77242}

Bug: v8:12209
Change-Id: I96e1ba33e97f6a4abbe20e23a8fdff6cdf8bc131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3207380Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77290}
      fed33f90
    • Samuel Groß's avatar
      Add PageInitializationMode enum for the BoundedPageAllocator · 18c37d32
      Samuel Groß authored 
      Currently, when compiling with V8_VIRTUAL_MEMORY_CAGE enabled, the
behavior of the BoundedPageAllocator changes from simply making freed
pages inaccessible to decommitting them, which guarantees that they will
be zero-initialized after the next allocation. As this seems to cause
some performance regressions on Mac, this CL introduces a new enum that
specifies how the allocator should behave:
kAllocatedPagesMustBeZeroInitialized causes the pages to be decommitted
during FreePages() and ReleasePages() and thus guarantees
zero-initialization during AllocPages().
kAllocatedPagesCanBeUninitialized only causes the pages to be made
inaccessible, and so does not generally guarantee zero-initialization
for AllocPages().

Finally, this CL also removes some dead code in allocation.cc.

Bug: chromium:1257089
Change-Id: I53fa52c8913df869bee2b536efe252780d1ad893
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208812
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77285}
      18c37d32
  37. 06 Oct, 2021 2 commits
    • Frank Tang's avatar
      Revert "[intl] Fix consistency in Intl API" · 34f278b8
      Frank Tang authored 
      This reverts commit a1e6efd8.

Reason for revert: Break Arm64

Original change's description:
> [intl] Fix consistency in Intl API
>
> Fix several edge cases consistency issues with ICU discovered by test262 test by
> using Intl Enumeration API
> 1. Work around ICU short coming of always fallback in currency display
>  name so when the fallback is "none" in DisplayNames, the force fallback
> code will produce the correct undefined from the of(currency_code) method.
> 2. Always check numbering system is not algorithm based numbering system
> to fix DateTimeFormat/RelativeTimeFormat/NumberFormat
> resolvedOptions().numberingSystem when the reqested numberingSystem is one
> of the numbering systems that we filter out the resources and not supported.
> 3. Generalize the iso8601 bit solution in DateTimeFormat and rename it to
> alt_calendar bit to also fix DateTimeFormat resolvedOptions report
> calendar as "islamic" while requesting "islamic-rgsa".
> 4. Work around reporting inconsistency of currency code and display name
> in ICU.
>
> Bug: v8:12209
> Change-Id: Ibd349ee55426fad7d6f20a5e93fb35ff7438e111
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3153576
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77242}

Bug: v8:12209
Change-Id: I6b8ac7dc89eda158e29c9d653825cb20a89341aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3207379Reviewed-by: 's avatarFrank Tang <ftang@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77246}
      34f278b8
    • Frank Tang's avatar
      [intl] Fix consistency in Intl API · a1e6efd8
      Frank Tang authored 
      Fix several edge cases consistency issues with ICU discovered by test262 test by
using Intl Enumeration API
1. Work around ICU short coming of always fallback in currency display
 name so when the fallback is "none" in DisplayNames, the force fallback
code will produce the correct undefined from the of(currency_code) method.
2. Always check numbering system is not algorithm based numbering system
to fix DateTimeFormat/RelativeTimeFormat/NumberFormat
resolvedOptions().numberingSystem when the reqested numberingSystem is one
of the numbering systems that we filter out the resources and not supported.
3. Generalize the iso8601 bit solution in DateTimeFormat and rename it to
alt_calendar bit to also fix DateTimeFormat resolvedOptions report
calendar as "islamic" while requesting "islamic-rgsa".
4. Work around reporting inconsistency of currency code and display name
in ICU.

Bug: v8:12209
Change-Id: Ibd349ee55426fad7d6f20a5e93fb35ff7438e111
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3153576
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77242}
      a1e6efd8
  39. 05 Oct, 2021 1 commit
  41. 01 Oct, 2021 1 commit
  43. 28 Sep, 2021 1 commit
  45. 23 Sep, 2021 1 commit
  47. 20 Sep, 2021 2 commits
  49. 17 Sep, 2021 1 commit
  51. 16 Sep, 2021 2 commits
  53. 14 Sep, 2021 1 commit