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}
The scope disables garbage collection and should be only used in
heap, deserializer, isolate bootstrap, and testing.
Change-Id: Ide95926ef32fd9362cd9134e883e1bd626cc3b11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083292
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66557}
After support for ARCH_PPC was dropped, it became a subset of
ARCH_PPC64. If you compile for ppc64, then you set the ARCH_PPC64
define which also sets the ARCH_PPC define.
To be able to again support ppc (32 bit) those defines should be
split up again.
This commit only splits up the defines but does not introduce a
working ARCH_PPC variant.
Bug: v8:10102
Change-Id: I64e0749f8e5a7dc078ee7890d92e57b82706a849
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989826
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66390}
Jitless mode does not allocate executable memory, so we can avoid reserving
memory in such configurations.
Bug: v8:10033
Change-Id: Ie6a943084e3bade85848e3219cb4d8779ed34830
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981505
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66388}
Introduce separate counters for young and old array buffer bytes. They
are used to keep the counter stable during sweeping when the array
buffer lists are moved to the concurrent thread for sweeping.
Bug: v8:10064
Change-Id: I0f11a634341873b4d21759c284c55beb26fe30a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045511
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66204}
Update external memory counters when using ArrayBufferExtensions. In
case the array buffers are swept concurrently, the counters are updated
at the beginning of the next minor/full GC. A subsequent GC is going
to update counters faster.
ArrayBufferExtension now stores the accounting_length such that
the sweeper always knows how much memory to deduct from the external
memory on destruction.
ArrayBufferList now also tracks the size of all ArrayBuffers in it.
Bug: v8:10064
Change-Id: I50a8b1180aa837b6932f834df1610255bd2bd9fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041441
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66195}
Now ResourceConstraints::ConfigureDefaults sets the heap limit to 4GB
if the physical memory size is greater or equal to 16GB on 64-bit
platforms.
This CL also adds tests for configuring heap limits from the physical
memory size.
Bug: chromium:1045034
Change-Id: If0d5a237b2db31309a9a2a6456d950ef70dc71af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043833
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66174}
When the embedder integrates in V8's garbage collector the performance
of the atomic phase is sensitive to how much embedder memory is found
through marking the overall transitive closure.
Before this patch, V8 would help out tracing the embedder's heap when
making progress through tasks but not on allocations. In addition, V8
would complete the garbage collection when it has observed it's own
marking worklists as empty 3 times (*). This can create performance
cliffs when there's a lot of work still to be done on the embedder
side.
This patch adds helping steps on allocation that are proportional to
the bytes that V8 would otherwise process, guaranteeing some progress
as long as there's V8 allocations. This allows us to remove (*).
Potential Tradeoffs:
- More time spent in V8's garbage collection metrics as we slightly
limit the chances for the embedder to mark objects through tasks.
- Prolonged V8.execute time (JS execution)
+ Faster progress
+ Less memory
+ Smaller atomic pause time
Change-Id: I160f063209f7e129b9c884206f833706b69dadc1
Bug: chromium:1044630
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2025371
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66091}
The flag is unused.
Bug: chromium:1044630
Change-Id: Ib499cdd559451c9f23c3c98b187755ef6748bffc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030743
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66070}
When ArrayBufferExtensions are enabled, sweep the extensions outside of
the GC pause concurrently to the application. The following GC will make
sure that the previous concurrent sweep operation is finished.
This CL introduces Heap::array_buffer_sweeper() that is both
responsible for tracking all extensions but also for sweeping.
Bug: v8:10064
Change-Id: I113cd625445a7d59ffb7a9de8b25a15a72b02b99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010107
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65984}
This adds a new API function that can be customized by the embedder
by providing a delegate that defines contexts to be measured and
reports the results to JS.
A memory measurement request is carried out as follows:
1) MeasureMemory(delegate) invocation enqueues a new request in
MemoryMeasurement::received_ and schedules a delayed GC task.
2) At the start of the next GC (that is triggered either by the
GC schedule or by the delayed task) each request in received_
moves to processing_. Per-context marking worklists are created
for each native context that was selected by the delegates
(using the ShouldMeasure predicate).
3) At the end of the GC the sizes of the native contexts are
recorded for each request in processing_. The requests move
to the done_ list and result reporting task is scheduled.
4) When the result reporting task runs it invokes the
MeasurementComplete function of each delegate in done_.
Bug: chromium:973627
Change-Id: I0254cae693c5b8fab7c85a9eca0a3a128210b6c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981493
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65856}
Split the linked list of array buffer extensions into two lists for
young and old JSArrayBuffers. Process young extensions during the
minor GC pause. When promoting JSArrayBuffers into the old gen, move
the extension into the old linked list as well.
Bug: v8:10064
Change-Id: I07275ffe7ba918c9b2d6d0648a6d1b59e4fa4891
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997438
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65842}
Similar to TracedReference, support TracedGlobal on stack as well.
Bug: chromium:1040038
Change-Id: If3400a2df8b4a11410032bd5ad1b7bed64063b93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2005071
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65841}
Previously, V8 was just relinking nodes which broke when a move involves
an on-stack reference as such nodes have different semantics.
The solution is to create new internal nodes when necessary.
Bug: chromium:1040038
Change-Id: Ia5b3866ae68d014beb30972c4266aa5bae6559fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002546
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65823}
- Introduces a API to set top of the stack through
EmbedderHeapTracer::SetStackTop.
- Introduces a new API to inform V8 about an empty embedder stack.
- Switch internal representation of TracedReference
for on-stack handles to a proper stack that considers all
contained handles as roots.
- Handle garbage is avoided by cleaning up on handle creation or
GC.
Design doc: https://bit.ly/on-stack-traced-reference
Bug: chromium:1040038
Change-Id: I927ef0abb268fdb5853c9e17b1bc96e2491cf101
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993973
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65757}
This adds inference for general JSObjects to NativeContextInferrer in
the case when the object is going to be attributed to the shard context.
Bug: chromium:973627
Change-Id: I393e8dd16a1f8b615fb2f8dceb52f543bae33554
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997133
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65736}
This CL adds the ArrayBufferExtension class, which is used to track
JSArrayBuffers in a linked list. The ArrayBufferExtension is going to
replace the ArrayBufferTracker in the future but is currently behind
the v8_enable_array_buffer_extension feature flag.
When enabled, each JSArrayBuffer has a corresponding native-heap
allocated ArrayBufferExtension object. All extensions are currently
tracked in a single linked list. During marking the GC not only
marks the JSArrayBuffer but also its extension object. At the end of
mark-compact the GC iterates all extensions and removes unmarked ones.
Change-Id: I88298be255944d5ae1327c91b0d7f0fdbcd486d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969791
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65724}
This changes the marking worklist draining for the main thread
marker and the concurrent marker to use the following algorithm in
per-context mode:
1) Pop an object from the marking worklist.
2) Try to infer the native context that owns the objects.
This is done using a new NativeContextInferrer class.
3) If the inference is successful, then change the active marking
worklist to the worklist of the inferred native context.
4) Otherwise, keep the current active marking worklist.
5) Visit the object. Newly discovered objects will be pushed
onto the active marking worklist.
6) Account the object size for the native context corresponding
to the active marking worklist.
This is done using a new NativeContextStats class.
The main property of the algorithm is that each object for which
we couldn't infer the native context is either attributed to
the native context retaining it or is not attributed to any native
context.
Bug: chromium:973627
Change-Id: Ide4ab992275d115279f971d89ace657f4c05e176
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981491
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65663}
It has been deprecated in v7.9, but needed to be changed
again for v8.0 by providing a default implementation. This
allowed embedders to remove all overrides. We can now
remove the definitions in v8.1.
R=ulan@chromium.org
CC=ahaas@chromium.org
Bug: v8:9810
Change-Id: I9d303bf8a01d863bce3522abccdd3ded5e551818
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868620
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65633}
This adds heuristics to perform young and full GCs on allocation
of external ArrayBuffer backing stores.
Young GCs are performed proactively based on the external backing
store bytes for the young generation. Full GCs are performed only
if the allocation fails. Subsequent CLs will add heuristics to
start incremental full GCs based on the external backing store bytes.
This will allow us to remove AdjustAmountOfExternalMemory for
ArrayBuffers.
Bug: v8:9701, chromium:1008938
Change-Id: I0e8688f582989518926c38260b5cf14e2ca93f84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803614
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65480}
Since RecordStats during GC, (when it fails to recover enough memory),
it unsafe for it to allocate any memory. Thus it cannot call PrintStack
which can call SharedFunctionInfo::EnsureSourcePositionsAvailable and
which may allocate, so this removes the call to PrintStack which is
apparently not useful for debugging anyway.
Bug: chromium:1032087
Change-Id: I94feeaab1445f7fd4f770a20197546fc40c77390
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967377
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65475}
This unifies marking worklists handling by the main thread marker and
by the concurrent markers. A new class called MarkingWorklistsHolder
owns all marking worklists: the default worklist, the on-hold worklist,
and the embedder worklist. Each thread creates a local view of the
marking worklists by creating an instance of MarkingWorklists.
Additionally, marking visitors now work on MarkingWorklists instead of
accessing each worklist individually.
Besides cleaning the code up, this CL provides a bottleneck for
implementing per-context worklists.
Bug: chromium:973627
Change-Id: I52ad65c94bc0695287ba7bf4d8a814a9035e2888
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1941947
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65421}
Currently a TracedNode of a TracedReference is freed only if its target
V8 object is unreachable. This is problematic for TracedNodes created for
long-living (or immortal) V8 objects and leads to memory leaks.
This CL adds logic for collecting unreachable TracedNodes:
1) Each TracedNode gets a markbit. Initially the markbit is set (i.e.
we have black allocation for TracedNodes).
2) During marking RegisterEmbedderReference sets the markbit of the
corresonding TracedNode.
3) In the atomic pause of Mark-Compact when TracedNodes are iterated,
we check the markbits and free TracedNodes with cleared markbits.
After this processing all markbits are cleared for the next GC.
Note that the new logic does not apply to TracedNode that have
callbacks and/or destructors.
Bug: chromium:1029738
Change-Id: I38e76a8b4a84170793998988b1a7962e40874428
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948722
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65347}
For many subclasses of JSObject, we used kSize instead of kHeaderSize
even though they can contain in-object properties. In fact, kSize
was very much used as the header size, as can be seen in many examples
in this CL.
This change is a preparation for a for a cleanup of how Torque
generates field offsets.
TBR=hpayer@chromium.org
Change-Id: I350e996057cd66c427381334080f8ac93de88597
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917141
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65013}
In Liftoff, we have a good estimate about how big the generated code
might get. Also, we often compile hundreds of functions which each hold
an assembler buffer alive until we finally add that code to the wasm
module.
In order to reduce memory consumption in Liftoff, this CL reduces
{AssemblerBase::kMinimalBufferSize} from 4096 to 128, and adds
{AssemblerBase::kDefaultBufferSize} to be used instead.
R=jkummerow@chromium.org
Change-Id: I7029bf501244770f4824a86b233d7f99c4b7910b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914559
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64958}
This is the first step in unification of concurrent and main thread
marking visitors. The new MarkingVisitorBase will become a base class
for all marking visitors and will remove the existing code duplication.
This is a refactoring without behavior change.
Subsequent CL will change the main thread marking visitor to derive
from the new base class.
Bug: chromium:1019218
Change-Id: I3d47030d396e0ba6706882fbd922bbcac46181b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886920
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64632}
The new API with v8::BackingStore should be used instead as explained in
https://docs.google.com/document/d/1sTc_jRL87Fu175Holm5SV0kajkseGl2r8ifGY76G35k
This also relaxes the pre-condition for [Shared]ArrayBuffer::Detach to
not require externalization first.
Bug: v8:9380, v8:9908
Change-Id: Idd119fcd28be84a2fae74ae86f7381fd997766f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859628
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64625}
When inlined allocations are disabled, the space->limit() does not point to the
end of the current page. Instead, it points to the current allocation pointer so
is the same as space->top().
See how the limit is computed, if heap()->inline_allocation_disabled(), then the
limit will be the same as the requested allocation area:
```
Address SpaceWithLinearArea::ComputeLimit(Address start, Address end,
size_t min_size) {
DCHECK_GE(end - start, min_size);
if (heap()->inline_allocation_disabled()) {
// Fit the requested area exactly.
return start + min_size;
} else if (SupportsInlineAllocation() && AllocationObserversActive()) {
// ...
} else {
// The entire node can be used as the linear allocation area.
return end;
}
}
```
If we want to simulate filling up a whole page in the new space, we can instead
look at the ToSpace's page_high() which will be the end of the current page in
which we're allocating.
Bug: v8:9906
Change-Id: I81113d151bc083cd22d17ea1a4fbae7fef9dff6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886914
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#64612}
This change begins making use of the fact that Torque now knows about
the relationship between classes and instance types, to replace a few
repetitive lists:
- Instance type checkers (single and range), defined in
src/objects/instance-type.h
- Verification dispatch in src/diagnostics/objects-debug.cc
- Printer dispatch in src/diagnostics/objects-printer.cc
- Postmortem object type detection in
tools/debug_helper/get-object-properties.cc
Torque is updated to generate four macro lists for the instance types,
representing all of the classes separated in two dimensions: classes
that correspond to a single instance type versus those that have a
range, and classes that are fully defined in Torque (with fields and
methods inside '{}') versus those that are only declared. The latter
distinction is useful because fully-defined classes are guaranteed to
correspond to real C++ classes, whereas only-declared classes are not.
A few other changes were required to make the lists above work:
- Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
and avoid conflicts with the new macro-generated IsFiller method. This
is the part I'm most worried about: I think the new name is an
improvement for clarity and consistency, but I could imagine someone
typing IsFiller out of habit and introducing a bug. If we'd prefer to
keep the name IsFiller, my other idea is to rename FreeSpace to
VariableSizeFiller and Filler to FixedSizeFiller.
- Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
- Normalized the dispatched behavior for BigIntBase and HeapNumber.
- Added a few new object printers.
Bug: v8:7793
Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64597}
Both LO_SPACE and NEW_LO_SPACE use the basic page management system of
LargeObjectSpace, but implement different AllocateRaw methods (with
the NEW_LO_SPACE version shadowing the LO_SPACE version).
To clean this up, and allow other future LargeObjectSpace implementations
(in particular, an off-thread variant), refactored the current
LargeObjectSpace into a base class, and make both LargeObjectSpace
(renamed to OldLargeObjectSpace) and NewLargeObjectSpace extend this
class.
Bug: chromium:1011762
Change-Id: I41b45b97f2611611dcfde677213131396df03a5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876824
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64560}
This function was only used for the write barrier since the store
buffer only stored slots and needed a way to get to the object's start.
Now that we insert into the remembered set directly from the write
barrier this isn't an issue anymore: the write barrier knows the
object start.
Change-Id: I701465ea40b7c4ee20404ecbcf3750e5fa6fd219
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876049
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64518}
Add FLAG_always_promote_young_mc that always promotes young objects
during a Full GC when enabled. This flag guarantees that the young gen
and the sweeping remembered set are empty after a full GC.
This CL also makes use of the fact that the sweeping remembered set is
empty and only invalidates an object when there were old-to-new slots
recorded on its page.
Bug: chromium:1014943
Change-Id: Idfb13dfbe76bad5ec8b485a60bebc30531aec649
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863201
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64348}
Use v8::Data as basetype for managed objects that can integrate with
v8::EmbedderHeapTracer.
Bug: v8:9841
Change-Id: Id3e06701207a23870cea89e1d7d334c48fcd3006
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856002
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64283}
This makes allocation of backing stores more robust by perfoming GCs
on allocation failure. The GCs help if there are existing large backing
stores that are retained by dead JSArrayBuffer objects.
Bug: chromium:1008938, v8:9380
Change-Id: Ic80b29214b8843427dfcdd141df71363821afe71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1855998
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64241}
When aborting evacuation of a page, the GC also needs to take care
of invalidated objects and recorded slots on the page. Add a test
to ensure that future changes do not break this behavior.
Bug: chromium:1012081
Change-Id: I110db67157e4b8c7fdb4d1061e9df6955b532a70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1855758
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64234}
TracedGlobalTrait was unable to override v8::TracedGlobal<v8::Object> for
avoiding the destructor because it is needed on the API surface itself and C++
ODR which prohibits specialization after template instantiation.
Avoid this problem by providing a separate type TracedReference
that, similar to TracedGlobal, is purely traced but avoids the destructor
completely. This only works for embedders that have their memory management
tied to V8 as it is prone to accessing already reclaimed objects otherwise.
Bug: chromium:995684
Change-Id: Iab4332ed417b26c58638a8f9389174cc355a305b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1840972
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64150}
For this, all Torque stub-linkage builtins use TFC instead of TFS,
with a custom descriptor added to interface-descriptors.h
To avoid having complex logic in the generated code, the new class
TorqueInterfaceDescriptor contains the logic to create a
CallInterfaceDescriptor from a signature consisting of TNode types.
As an example and test, this CL ports StringCharAt to Torque.
Bug: v8:7793
Change-Id: I8339d2ad6e4f908ebdc3b8d30244e4bcbd974f21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1798427
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64148}
This CL removes the StoreBuffer and inserts slots into the
RememberedSet directly from within the RecordWrite builtin. Only calls
into C code when either the SlotSet-array or the bucket is not
allocated. This avoids filling the store buffer up with duplicates or
due to a write-heavy workload and then blocking the main thread on
store buffer processing.
The first CL (https://crrev.com/c/1815241) got reverted, because
mksnapshot was using a different size for SlotSet than the final
binary on ARM. This is fixed now, SlotSet has a standard layout.
Bug: v8:9454
Change-Id: I881641f4ee08a8b42c36fdca8733138b908096bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1842452
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64126}
Now that sweeping uses its own RememberedSet, pre-freeing of empty
buckets is not necessary anymore. Mutator inserts into a different
remembered set, than the sweeper removes slots from.
Bug: v8:9454
Change-Id: I65d046926aa82aeb9eca7694e6a7eff1331d7e01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1835547
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64114}
