Skip to content

V
V8
Switch branch/tag
  1. 24 Nov, 2020 1 commit
    • Leszek Swirski's avatar
      [utils] Add CompareCharsEqual · 52cfffde
      Leszek Swirski authored 
      Add a CompareCharsEqual to complement CompareChars, where we only care
about equality and not ordering. For such cases, we can memcmp for two-
byte as well as one-byte strings (we can't for CompareChars because the
ordering would be incorrect on little-endian systems).

Replace uses of CompareChars that only compare the result against zero,
with CompareCharsEqual. Additionally, use some template magic to
simplify the "make unsigned" operation in these methods.

Change-Id: I0d65bee81b98d3938d15daa4af331c90558ea84f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557980
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71385}
      52cfffde
  3. 23 Nov, 2020 1 commit
  5. 20 Nov, 2020 1 commit
  7. 17 Nov, 2020 1 commit
  9. 16 Nov, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add string access lock to GetChars · df842562
      Leszek Swirski authored 
      Add a requirement to String::GetChars that we either have a string
access lock, or a string access lock is not needed. This prevents us
from reading strings during internalization that may be in the middle
of being made external.

To avoid taking the lock too often when known to be unnecessary (e.g.
for strings that were only just created), there's now a static
SharedStringAccessGuardIfNeeded::NotNeeded(). This is hopefully ugly
enough that it's used sparingly.

One fix required for this is to enter the Isolate when tearing down
IsolateData in inspector tests -- this is so that the V8Inspector
instance being torn down will see the current Isolate and be able to
verify its thread id against the current thread.

Bug: chromium:1011762, chromium:1148680
Change-Id: Ic5d29c1b066ebae5a351c7b4bb116b9b1bf61889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536465
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71197}
      df842562
  11. 12 Nov, 2020 1 commit
    • Daniel Clark's avatar
      Sort import assertions by code point order of the keys · 73f8a710
      Daniel Clark authored 
      Per https://tc39.es/proposal-import-assertions/#sec-assert-clause-to-assertions,
import assertions should be sorted by the import assertion [[Key]]s,
in order to prevent hosts from relying on a changing order of the
assertions to determine behavior.

Prior to this change, the assertions were being sorted by pointer. With
this CL, the keys are sorted using a code point ordering so that the
order of the assertions received by the host will be stable and
non-surprising.

This CL also switches the SourceTextModuleDescriptor's ModuleRequestMap,
RegularExportMap, and RegularImportMap to use the code point order
comparison rather than their former shortlex sort.  This change will not
be externally visible, but it seems best to make these consistent.

In order to avoid #including the fairly large ast-value-factory.h
into ast/modules.h, I changed ImportAssertions into a separate class
definition rather than keeping it as a typedef.  The alternative would
be to define a common AstRawStringComparer in ast-value-factory.h and
then #include ast-value-factory.h in both ast/modules.h and
parsing/parser.h so that the ImportAssertions typedef would have a
full, shared definition of the AstRawStringComparer type.

Bug: v8:10958
Change-Id: I29c9544aa0a4340c56e1ee631be6cabb2a2eb921
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2533038
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71165}
      73f8a710
  13. 11 Nov, 2020 1 commit
  15. 26 Oct, 2020 1 commit
  17. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored 
      This patch introduces a new LocalIsolate and LocalFactory, which use
LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
us to remove those classes, as well as the related OffThreadSpace,
OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
OffThreadLogger becomes LocalLogger.

LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
us to additionally remove the concept of "Finish" and "Publish" that the
OffThreadIsolate had, and allows us to internalize strings directly with
the newly-concurrent string table (where the implementation can now move
to FactoryBase).

This patch also removes the off-thread support from the deserializer
entirely, as well as removing the LocalIsolateWrapper which allowed
run-time distinction between Isolate and OffThreadIsolate. LocalHeap
doesn't support the reservation model used by the deserializer, and we
will likely move the deserializer to use LocalIsolate unconditionally
once we figure out the details of how to do this.

Bug: chromium:1011762

Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  19. 10 Jul, 2020 1 commit
  21. 06 May, 2020 2 commits
    • Leszek Swirski's avatar
      [offthread] Unify compiler.cc finalization logic · 58b12f63
      Leszek Swirski authored 
      This patch unfies the finalization logic between the various unoptimized
compilation paths in compiler.cc, taking the various post-processings and
fixups needed for off-thread finalization and performing them in the same
order for the other finalizations.

It also unifies the general compilation path between streaming script
compilation, main-thread script compilation, and main-thread lazy
compilation, making the main-thread paths both use an iterative execution
and finalization, and making all three use the same job helper methods
and overall finalization helper.

Bug: chromium:1011762
Change-Id: Ibe56f6d2f75a2deffbe9e0b600ded8a02293b722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172790
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67609}
      58b12f63
    • Leszek Swirski's avatar
      [parser] Move Compiler::Analyze into Parser · 65d738d4
      Leszek Swirski authored 
      Move rewriting, scope analysis, and internalization, to be unconditional
operations done after parsing rather than a separate compile phase. This
removes some of the complexity about rememberering when to call
Compiler::Analyze, and makes these paths a bit more uniform.

Also, forbid allocating any more AST strings after AstValueFactory
internalization, by nulling out the Zone. Add an InternalizePartial
method which doesn't null out the zone for those cases where we do want
to be able to allocate after internalizing (e.g. internalization before
scope analysis).

Change-Id: Id444246d8362a1d169baf664fc37657d9576fd96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182458Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67608}
      65d738d4
  23. 02 Mar, 2020 1 commit
  25. 17 Feb, 2020 1 commit
  27. 10 Feb, 2020 1 commit
  29. 07 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [ast] Cache allocated AstConsString · 7fa19160
      Leszek Swirski authored 
      Allow caching the result of allocating AstConsStrings, to allow
sharing of inferred names between functions.

This is a partial revert of https://crrev.com/c/2020953, with
the observation that *some* AstConsStrings are always flattened,
while others are only ever used as ConsStrings, so we want to
allow the allocation to be lazy while still caching the result.

As a drive-by, cleanup the old AstConsString linked list fields.

Bug: chromium:1011762
Bug: chromium:1048082
Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66168}
      7fa19160
  31. 04 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add an OffThreadIsolate · 7a20b6b9
      Leszek Swirski authored 
      The Factory/OffThreadFactory allows us to cleanly separate object
construction behaviour between main-thread and off-thread in a
syntactically consistent way (so that methods templated on the factory
type can be made to work on both).

However, there are cases where we also have to access the Isolate, for
handle creation or exception throwing. So far we have been pushing more
and more "customization points" into the factories to allow these
factory-templated methods to dispatch on this isolate behaviour via
these factory methods. Unfortunately, this is an increasing layering
violation between Factory and Isolate, particularly around exception
handling.

Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
way as OffThreadFactory is analogous to Factory. All methods which were
templated on Factory are now templated on Isolate, and methods which
used to take an Isolate, and which were recently changed to take a
templated Factory, are changed/reverted to take a templated Isolate.
OffThreadFactory gets an isolate() method to match Factory's.

Notably, FactoryHandle is changed to "HandleFor", where the template
argument can be either of the Isolate type or the Factory type (allowing
us to dispatch on both depending on what is available).

Bug: chromium:1011762
Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66101}
      7a20b6b9
  33. 30 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [ast] Allocate cons strings on-demand · ddca3606
      Leszek Swirski authored 
      Remove AstConsString "internalization", and instead make the conversion
to heap String be on-demand with an Allocate method. We never actually
need the heapified cons string more than once, so there's no need to do
the internalization walk or do the next/string union dance in the
AstConsString class.

This also allows us to specify how we want to allocate the String at the
call site. In particular, it allows us to allocate a flat SeqString rather
rather than a ConsString. This allows us to avoid allocating ConsStrings
which will just be passed to a flatten call, and especially avoid
allocating dead ConsStrings in the off-thread old space.

Bug: chromium:1011762
Bug: chromium:1043168
Change-Id: Id851f2f7529d92ad7e5388eb22823fd6d1959cd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020953Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66042}
      ddca3606
  35. 29 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [ast] Allocate cons strings in young space on main thread · 60f108f9
      Leszek Swirski authored 
      In the case of function names, we allocate ConsStrings only to flatten
them during finalization. Allocating these ConsStrings in old space
appears to have regressed some benchmarks (especially memory benchmarks),
but is necessary for off-thread allocation which doesn't have a young
space.

Ideally, we would avoid allocating these ConsStrings in the first place,
and would flatten the data directly from the AstConsString. For now, we
make them allocate in old space for off-thread allocation only, to
revert the regressions. In the future we can investigate smarter
flattening.

Bug: chromium:1011762
Bug: chromium:1044477, chromium:1044147, chromium:1043573, chromium:1043168
Change-Id: If24b738d6f2eeb8c0fea042a711deb2a19015fbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020948
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66025}
      60f108f9
  37. 17 Jan, 2020 1 commit
  39. 16 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored 
      Add support for internalizing an AstValueFactory using the off-thread
factory. Includes adding ConsString support to OffThreadFactory.

This introduces a Handle union wrapper, which is used in locations that
can store a Handle or an OffThreadHandle. This is used in this patch for
the internalized "string" field of AST strings, and will be able to be
used for other similar fields in other classes (e.g. the ScopeInfo
handle in Scope, object boilerplate descriptor handles, the inferred
name handle on FunctionLiterals, etc.). It has a Factory-templated
getter which returns the appropriate handle for the factory, and a
debug-only tag to make sure the right getter is used at runtime. This
union wrapper currently decomposes implicitly to a Handle if the getter
is not called, to minimise code changes, but this implicit conversion
will likely be removed for clarity.

Bug: chromium:1011762
Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  41. 08 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      Revert "[ast] Add a Flatten method for AstConsString" · 4765addf
      Leszek Swirski authored 
      This reverts commit 7a0ae73b.

Reason for revert: Not useful after all, no tests, we can reland if we
do end up needing it.

Original change's description:
> [ast] Add a Flatten method for AstConsString
> 
> This allows off-thread flattening.
> 
> Bug: chromium:1011762
> Change-Id: If83f7bbcbf74165987a4c157184f5b92dc554971
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924437
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65075}

TBR=leszeks@chromium.org,verwaest@chromium.org

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

Bug: chromium:1011762
Change-Id: Ia72e5abdc9b6149a337565576806427dcd1d11c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991484Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65638}
      4765addf
  43. 20 Nov, 2019 2 commits
  45. 23 May, 2019 2 commits
  47. 21 May, 2019 1 commit
  49. 06 May, 2019 1 commit
  51. 03 May, 2019 1 commit
    • Sigurd Schneider's avatar
      Revert "Reland "[json] Speed up json parsing"" · 47fccbfd
      Sigurd Schneider authored 
      This reverts commit bbd740f0.

Reason for revert: blocks lkgr due to layout test failure:
https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/31607

Original change's description:
> Reland "[json] Speed up json parsing"
> 
> This is a reland of b0c4a876
> 
> Original change's description:
> > [json] Speed up json parsing
> >
> > - scan using raw data pointers + GC callback
> > - scan using scanner tables
> > - cap internalizing large string values
> > - inline fast transitioning logic
> >
> > Fixes previous CL by moving AllowHeapAllocation to callers of
> > ReportUnexpectedCharacter where needed to make it clear we need to exit.
> >
> > Tbr: ulan@chromium.org
> > Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#61159}
> 
> Tbr: verwaest@chromium.org
> Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
> Change-Id: Ic7d0057178c649fc45b8c8f4587ee9128e351515
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593292
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61179}

TBR=ulan@chromium.org,ishell@google.com,verwaest@google.com,ishell@chromium.org,verwaest@chromium.org

Change-Id: I3ae8f9ce8214bebe7fab9d87c5daf8cdfdb94199
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594438
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61194}
      47fccbfd
  53. 02 May, 2019 3 commits
  55. 30 Apr, 2019 4 commits
  57. 29 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored 
      Our {Vector} template provides both {start} and {begin} methods. They
return exactly the same value. Since the {begin} method is needed for
iteration, and is also what standard containers provide, this CL
switches all uses of the {start} method to use {begin} instead.

Patchset 1 was auto-generated by using this clang AST matcher:
    callExpr(
        callee(
          cxxMethodDecl(
            hasName("start"),
            ofClass(hasName("v8::internal::Vector")))
        ),
        argumentCountIs(0))

Patchset 2 was created by running clang-format. Patchset 3 then
removes the now unused {Vector::start} method.

R=jkummerow@chromium.org
TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org

Bug: v8:9183
Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  59. 11 Mar, 2019 1 commit
  61. 25 Jan, 2019 1 commit
  63. 26 Dec, 2018 1 commit