Both NewSpace and NewLargeObjectSpace aren't used with
FLAG_single_generation enabled. So far both spaces still existed but
weren't used in this mode. This CL makes both spaces optional, which
ensure that we do not inadvertently create objects in them or use them
in any other way.
Bug: v8:11644
Change-Id: I52a449c62e9d3df126c95419433d2abbd75539a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2862768
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74345}
We previously assumed that a fake stack should be mapped back to a
real stack based on fake-stack offsets. This is not correct: Fake and
real stack are disjoint and both contain the corresponding slot
values.
For global handles this means that on-stack handles must be registered
using their real stack frame base to be able to purge them
occasionally based on the current stack address.
When dealing with a slot though, the GC can just dereference the slot
for a value, indeppendent of whether the slot is in a fake or real
frame.
Drive-by: Fix tests that do not want stack handles by creating
handles on heap.
Change-Id: I2c86c8e047bd0d48c24c2642b2b4dba284a93909
Bug: chromium:1139914
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507720
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70897}
In many cases, this simply requires early returning from tests which
rely on scavenger.
Bug: v8:10614
Change-Id: I5fc93b1cbc807b73bfbb113d087952e347001ddd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270548
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jake Hughes <jakehughes@google.com>
Cr-Commit-Position: refs/heads/master@{#68702}
Report the allocated size of global handles in GetHeapStatistics as
well, not including free handles.
Bug: chromium:1060192
Change-Id: I1aedba36735f897cd8518edbb5ef2261cc348bff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093493
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66651}
String::NewFromLiteral is a templated function that takes a char[N]
argument that can be used as an alternative to String::NewFromUtf8 and
returns a Local<String> rather than a MaybeLocal<String> reducing the
number of ToLocalChecked() or other checks.
Since the string length is known at compile time, it can statically
assert that the length is less than String::kMaxLength, which means that
it can never fail at runtime.
This also converts all found uses of NewFromUtf8 taking a string literal
or a variable initialized from a string literal to use the new API. In
some cases the types of stored string literals are changed from const
char* to const char[] to ensure the size is retained.
This API does introduce a small difference compared to NewFromUtf8. For
a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
would treat this as a 3 character string, whereas the new API will treat
it as a 7 character string.
As a drive-by fix, this also fixes all redundant uses of
v8::NewStringType::kNormal when passed to any of the String::New*
functions.
Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66622}
Report the total size of global handles in GetHeapStatistics as well.
This size includes used and free global handles.
Change-Id: I08c0647d993a810a37ae9f332732de9551b5ea8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083020
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66562}
Especially for function types, this increases readability significantly.
Also the style guide recommends for 'using' over 'typedef'.
R=mstarzinger@chromium.org
Bug: v8:9183
Change-Id: If2d17863de39383f5a35e089298d37408791ce4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631415
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61872}
This replaces all typedefs that define types and not functions by the
equivalent "using" declaration.
This was done mostly automatically using this command:
ag -l '\btypedef\b' src test | xargs -L1 \
perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
Patchset 2 then adds some manual changes for typedefs for pointer types,
where the regular expression did not match.
R=mstarzinger@chromium.orgTBR=yangguo@chromium.org, jarin@chromium.org
Bug: v8:9183
Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61849}
This CL was generated by an automatic clang AST rewriter using this
matcher expression:
callExpr(
callee(
cxxMethodDecl(
hasName("operator->"),
ofClass(isSameOrDerivedFrom("v8::internal::Object"))
)
),
argumentCountIs(1)
)
The "->" at the expression location was then rewritten to ".".
R=jkummerow@chromium.orgTBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org
Bug: v8:9183, v8:3770
No-Try: true
No-Tree-Checks: true
Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61764}
This ensures that ApiObjects in V8 are not dropped if they are
currently used as WeakCollection keys. As proxy to determine key
status we use the presence of the identity hash on the object.
R=ulan@chromium.org
Bug: v8:8557, chromium:949244
Change-Id: Ifa0e24be44431a0200fd6a1d9898cd366b940bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557143
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60675}
This takes heap-inl.h out of the "Giant Include Cluster".
Naturally, that means adding a bunch of explicit includes
in a bunch of places that relied on transitively including
them before.
As of this patch, no header file outside src/heap/ includes
heap-inl.h.
Bug: v8:8562,v8:8499
Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4
Reviewed-on: https://chromium-review.googlesource.com/c/1459659
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59617}
Most of the users of InNewSpace actually mean InYoungGeneration.
Subsequent CL will remove InNewSpace to avoid confusion.
Bug: chromium:852420
Tbr: mlippautz@chromium.org
Change-Id: I6234d162d51c215787972e7ada1cd5b804b60fda
Reviewed-on: https://chromium-review.googlesource.com/c/1463521
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59523}
In future, weak handles will be considered as independent and MarkActive() will
not be supported anymore. Users should switch to TracedGlobal, when relying on
special cases for using handles with v8::EmbedderHeapTracer.
Bug: chromium:923361, v8:8562
Change-Id: Ic6e01a1ab59a25c5fb0aa2ebfb8ddb02e454d72d
Reviewed-on: https://chromium-review.googlesource.com/c/1443064
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59194}
TracedGlobal integrates with the use case of EmbedderHeapTracer and replaces
regular weak Global or Persistent nodes for such cases. This allows to simplify
the case for regular weak handles in a sense that they follow regular weak
semantics (if the underlying object is otherwise unreachable the weak handle
will be reset).
TracedGlobal requires slightly different semantics in the sense that it can be
required to keep them alive on Scavenge garbage collections because there's a
transitive path that is only known when using the EmbedderHeapTracer.
TracedGlobal accomodates that use case.
TracedGlobal follows move semantics and can thus be used in regular std
containers without wrapping data structure.
The internal state uses 20% less memory and allows for only iterating those
nodes when necessary. The design trades the virtual call when iterating
interesting persistents in the GC prologue with calling out through the
EmbedderHeapTracer for each node which is also a virtual call. There is one less
iteration over the set of handles required though and the design is robust
against recursive GCs that mutate the embedder state during the prologue
callback.
Bug: chromium:923361
Change-Id: Idbacfbe4723cd12af9de21058a4792e51dc4df74
Reviewed-on: https://chromium-review.googlesource.com/c/1425523
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59183}
v8::Global may be used as a weak reference. In the case this reference is a
simple phantom reference, we need to update the internal state to be able to
clear the right slot once the object referred to is dead.
This reverts commit 18f32ca89c.
Bug: chromium:924220
Change-Id: I3caec77448b0c5fcb461c8f8b5015de2978b3931
Reviewed-on: https://chromium-review.googlesource.com/c/1430015
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59055}
This reverts commit 584f0b43b2.
Reason for revert: Breaks MSAN build - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/24872
Original change's description:
> [api, global-handles] Fix moving weak Global<T>
>
> v8::Global may be used as a weak reference. In the case this reference is a
> simple phantom reference, we need to update the internal state to be able to
> clear the right slot once the object refered to is dead.
>
> Bug: chromium:924220
> Change-Id: I2ab7c3afcbe22988791faef406c284db03a43caf
> Reviewed-on: https://chromium-review.googlesource.com/c/1430101
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59040}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: I19c3e929962203df4e1f24191d054180723b1c9d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:924220
Reviewed-on: https://chromium-review.googlesource.com/c/1430833
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59046}
v8::Global may be used as a weak reference. In the case this reference is a
simple phantom reference, we need to update the internal state to be able to
clear the right slot once the object refered to is dead.
Bug: chromium:924220
Change-Id: I2ab7c3afcbe22988791faef406c284db03a43caf
Reviewed-on: https://chromium-review.googlesource.com/c/1430101
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59040}
The change is just a refactoring without functional changes.
Bug: chromium:923361
Change-Id: Ie633c56122ff72658f0238dc40db698350a7b8e7
Reviewed-on: https://chromium-review.googlesource.com/c/1421363
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58963}
The DCHECK was overly restrictive when checking that a weak handle is
not a finalizer when hitting it through a regular scavenge processing
path.
Only happened with finalizers to unmodified API wrappers or regular
objects that were also marked as independent.
Bug: v8:8586
Change-Id: I2c2a5b21f6e8a5ddc6671f762b508ba083c04335
Reviewed-on: https://chromium-review.googlesource.com/c/1387485
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58414}
Heap::InNewSpace only needs to access the heap for a DCHECK and the part
that uses the heap only needs it if the object is in NEW_SPACE, in which
case getting it via pointer magic is fine.
Bug: v8:7786
Change-Id: Iaac237a3b8bcc9d55e436e3f972475e04b97f1f8
Reviewed-on: https://chromium-review.googlesource.com/1127798
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54345}
Currently we rely on tasks to invoke the second pass phantom callbacks.
This may accumulate phantom callbacks and make GCs ineffective if we
do not enter the message loop to run the tasks between the GCs.
Bug: v8:7912
Change-Id: I799c97ff99ed6967480bda24ea0bf1c6a7dd69be
Reviewed-on: https://chromium-review.googlesource.com/1122621
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54144}
There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.
This saves about 20KB of binary size on x64.
Original review: https://chromium-review.googlesource.com/c/v8/v8/+/959533
Originally landed as r52416 / f9a2e24bbc
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Id072cbe6b3ed30afd339c7e502844b99ca12a647
Reviewed-on: https://chromium-review.googlesource.com/1000540
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52492}
This reverts commit f9a2e24bbc.
Reason for revert: gc stress failures not all fixed by follow up.
Original change's description:
> [cleanup] Refactor the Factory
>
> There is no good reason to have the meat of most objects' initialization
> logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
> this CL changes the protocol between Heap and Factory to be AllocateRaw,
> and all object initialization work after (possibly retried) successful
> raw allocation happens in the Factory.
>
> This saves about 20KB of binary size on x64.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
> Reviewed-on: https://chromium-review.googlesource.com/959533
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52416}
TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/999414
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52420}
There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.
This saves about 20KB of binary size on x64.
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
Reviewed-on: https://chromium-review.googlesource.com/959533
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52416}
Persistent handles are always independent these days. Users should mark
weak handles as active using MarkActive if they want to keep weak
handles that are otherwise unreachable alive across scavenges.
Bug: chromium:780749
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I116e984ce14a035d1cef491d49f11a388fa8169d
Reviewed-on: https://chromium-review.googlesource.com/759794
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49456}
Removes the handling of the flag independent. The flag will be removed in a followup.
The patch changes handling of V8::PersistentBase that are set to Weak:
- The Scavenger ignores the flag independent.
- The Scavenger keeps alive anything that is marked as Active.
- The Scavenger is free to drop weak handles of non-Active object if they
are otherwise dead.
Active:
- Any JSObject will always be marked Active.
- Any JSApiObject will be marked Active if it has been modified (=has elements, properties, etc.)
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Bug: chromium:780749
Change-Id: If1f547f2419930ad9400bd3b11bdbf609cb57649
Reviewed-on: https://chromium-review.googlesource.com/741801
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49277}
Resetting phantom handles while keeping finalizers alive leads to the
problem of eagerly resetting a handle although another finalizer keeps
it (transitively) alive.
This becomes a problem with internal pointers to Blink as without
global handle a Blink GC is free to collect wrappables.
This CL untangles finalizers handling from phantom handle resets by
introducing a separate path for resetting.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Bug: chromium:781728
Change-Id: Ica138b72942698fd996c6e9fe0bdc19cc432c010
Reviewed-on: https://chromium-review.googlesource.com/753724
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49162}
Phantom handles were processed at the same time as finalizers. This
meant that if a finalizer kept an object alive the phantom handle
was still destroyed.
This becomes a problem in the context of Blink GCs where internal
fields are roots for Blink. Prematurely destroying a phantom handle
can lead to stale pointers.
Bug: chromium:772299
Change-Id: If02365c457be8ce48379ad357cce36baa9617cfb
Reviewed-on: https://chromium-review.googlesource.com/750625
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49086}
* Avoid "using namespace" statements, which trigger clang's -Wheader-hygiene
warnings in jumbo builds.
* Undefine created macros at the end of source files.
BUG=chromium:746958
Change-Id: I5d25432c314437f607b0e1be22765a6764267ba6
Reviewed-on: https://chromium-review.googlesource.com/610962
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#47347}
Downside: this adds all kinds of weird includes in the .cc files.
(See design doc linked in the bug.)
BUG=v8:5402
Review-Url: https://codereview.chromium.org/2622503002
Cr-Commit-Position: refs/heads/master@{#42140}
Now callers of Heap::CollectGarbage* functions need to
specify the reason as an enum value instead of a string.
Subsequent CL will add stats counter for GC reason.
BUG=
Review-Url: https://codereview.chromium.org/2310143002
Cr-Commit-Position: refs/heads/master@{#39239}
Rebuilding (after touching certain files) is crazy slow because
includes are out of control. Many of these files we need to rebuild are
cctests which pull in more includes than they need.
BUG=v8:5294
Review-Url: https://codereview.chromium.org/2304553002
Cr-Commit-Position: refs/heads/master@{#39080}
