Change the unittest runner to no longer uncondtionally set up a default
platform in the "environment", but to instead make platform set-up part
of the "mixin" framework for test fixtures.
Requires modifying some tests that expect the platform to be available,
and all flag implications resolved, before the mixin constructors run.
We still keep the environment for setting up the process for cppgc. This
process setup can only be done once per process, so it can no longer use
the platform -- that's ok though, the page allocator used by cppgc's
process initialisation doesn't have to be the same as the platform's so
we can just pass in a separate new one.
Change-Id: Ic8ccf39722e8212962c5bba87350c4b304388a7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571886
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79820}
... by migrating old-style code
MyObject* obj = new (zone) MyObject(...)
to the new style
MyObject* obj = zone->New<MyObject>(...)
... and prohibiting accidental use of the old-style.
Bug: v8:10689
Change-Id: Id75774ac12e3d0f95cb3a538066dffbf7815e438
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300490
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68905}
This pooling introduces severe lock contention for Liftoff compilation,
since each compilation uses its own Zone which does at least one
segment allocation.
It's also unclear whether pooling improves performance, since {malloc}
should implement a similar pooling mechanism, but better optimized for
multithreaded uses.
Feel free to revert if this introduces significant regressions.
R=verwaest@chromium.org
Bug: v8:8916
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Change-Id: Iaf988bed898e35700f5f7f3310df8e01918de4c9
Reviewed-on: https://chromium-review.googlesource.com/c/1491632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59959}
Unfortunately the previous strategy was slower but more memory efficient. For now simply revert.
Revert "[zone] Use 32kb instead of 1MB as high zone page size"
Revert "[zone] Get rid of the Zone's segment pool"
Revert "[zone] Further simplify zone expansion, use single default page size"
Bug: chromium:908359
Change-Id: I649542e7e61eef0c14a26ffd21039e8340ab4d04
Reviewed-on: https://chromium-review.googlesource.com/c/1351027
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57872}
We would return the wrong chunk for the first element past the chunk
boundary, e.g. if the first chunk was size=8, then Find(8) would
return an address in the first block rather than the second one.
Bug: v8:8077
Change-Id: I90281f853dd7ca68dc065ed773d0ae9787f00988
Reviewed-on: https://chromium-review.googlesource.com/1183483
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55294}
Replace most uses of ZoneList in the parser with ZoneChunkList, which is
more Zone allocation friendly. Includes rewriting some index-based loops
as iterator-based, since ZoneChunkList random access isn't constant
time.
Bug: v8:7754
Change-Id: I49052b8afb90a4f3bfbe4076c2f90505b598e47a
Reviewed-on: https://chromium-review.googlesource.com/1145382
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54631}
With the current attempt, trying to iterate a const ZoneChunkList doesn't even
compile. See the bug for more info.
R=marja@chromium.org
Bug: v8:6473
Change-Id: I8de7e887398be7ba5da14dc540dd40b30df2c3fe
Reviewed-on: https://chromium-review.googlesource.com/868332
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50675}
Perf Sheriffs: This CL may change performance on various benchmarks.
BUG=chromium:716032
Review-Url: https://codereview.chromium.org/2895473003
Cr-Commit-Position: refs/heads/master@{#45495}
A std::deque interacts badly with zone memory in that it allocates chunks
of memory for the back of the queue and frees memory from the front of the
queue. As such we never reuse zone memory for the queue. Implement a very
simple RecyclingZoneAllocator which keeps a single block of memory from
deallocation that can be reused on allocation.
Also clean up zone-allocator a bit and make it use proper Chromium coding
style.
BUG=chromium:700364
Change-Id: I19330a8a9ec6d75fe18d8168d41f1a12030a6c4d
Reviewed-on: https://chromium-review.googlesource.com/458916
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44154}
This CL modifies the ast-numbering phase to collect function literals which
should be compiled eagerly. This is then used to eagerly compile the inner
functions before compiling the outer function. This will be used to queue
compilation jobs on the CompilerDispatcher in a later CL.
This CL moves the compilation of eager inner functions out of the
GetSharedFunctionInfo function and instead compiles them explicitly. This
simplifies GetSharedFunctionInfo and also means there is no need to pass a
LazyCompilationMode to the function, so this concept has been removed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2618553004
Cr-Commit-Position: refs/heads/master@{#42221}
Exchanged the ZoneList for a ZoneChunkList to avoid
unnecessary growing.
Review-Url: https://codereview.chromium.org/2468183004
Cr-Commit-Position: refs/heads/master@{#40736}
Since ZoneLists are essentially non-standard ZoneVectors and have a bad
growing behaviour (ZoneList-allocations make up ~50% of website parse
zone memory) we should stop using them. The zone-containers are merely
a clean-up, with none of them actually better suited to be used with
zones. This new datastructure allows most operations of a LinkedList (
except pop_first and insertAt/removeAt) but uses about the same memory
as a well-initialized ZoneVector/ZoneList (<3% overhead with reasonably
large lists). It also never attempts to free memory again (which would
not work in zones anyway).
The ZoneChunkList is essentially a doubly-linked-list of arrays of
variable size.
Some test-results where I tried storing 16k pointers in different list
types (lists themselves also zone-allocated):
List type Zone memory used Time taken
-----------------------------------------------------------------------
Zone array (for comparison) 131072 B
Ideally initialized ZoneList 131088 B 0.062ms
ChunkZoneList 134744 B 0.052ms <--new thing
ZoneDeque 141744 B
ZoneLinkedList 393264 B
Initially empty ZoneList 524168 B 0.171ms <--right now
ChunkZoneList only push_front 524320 B
Review-Url: https://codereview.chromium.org/2449383002
Cr-Commit-Position: refs/heads/master@{#40602}
Added a size constraint to the configuration to limit the segment pool.
This will likely fix the memory alerts from small android devices.
BUG=chromium:655129
Review-Url: https://chromiumcodereview.appspot.com/2424393002
Cr-Commit-Position: refs/heads/master@{#40476}
