This CL fixes comparison operations that take into account full-word
value instead of the lower 32 bits and tweaks some CSA helper functions
for smi-corrupting decompression.
Bug: v8:9706
Change-Id: I50e38a9f34b911ec0b8dd4e21298417bf23160aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1824943
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63995}
This adds an additional V8 API to get the backing store of an array
buffer. Unlike the existing API, the backing store comes wrapped
in a std::shared_ptr, making lifetime management with the embedder
explicit. This obviates the need for the old GetContents() and
Externalize() APIs, which will be deprecated in a future CL.
Contributed by titzer@chromium.org
Bug: v8:9380
Change-Id: I8a87f5dc141dab684693fe536b636e33f6e45173
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807354
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63883}
Replace uses of WordEqual on two tagged representation nodes with a new
TaggedEqual helper, which on pointer compressed configs only compares
the bottom 32-bits of the word. We no longer allow using WordEqual on
anything not known to be a WordT (i.e. Node* or TNode<Object>).
In the future, this may allow us to ignore the top bits of an
uncompressed Smi, and have simpler decompression, though this patch is
not sufficient for such a change.
As a necessary drive-by, TNodify a bunch of stuff.
Bug: v8:8948
Change-Id: Ie11b70709e5d3073f12551b37b420a172a71bc99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763531
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63372}
Since the mutability of HeapNumbers is determined by their owning
object's descriptor array, we can remove the MutableHeapNumber type
entirely, at the cost of a few fewer DCHECKs and a couple of TODOs
to use the descriptor array information.
This is a necessary step towards a follow-up which allows in-place
Double -> Tagged transitions
Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/
Bug: v8:9606
Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63294}
In generated code, we access fields inside IsolateData through the
root-register. On some platforms it is significantly cheaper to access
things that are close to the root-register value than things that are
located far away. The motivation for this CL was a 5% difference in
Octane/Mandreel scores between
// Part of the stack check.
cmpq rsp,[r13+0x9ea8]
and
cmpq rsp,[r13-0x30] // Mandreel score improved by 5%.
This moves the StackGuard up to fix Mandreel. As a drive-by, also move
two more fields up that are accessed by each CallCFunction.
Tbr: yangguo@chromium.org
Bug: v8:9534,chromium:993264
Change-Id: I5418b63d40274a138e285fa3c99b96e33a814fb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751345
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63187}
... which works properly when intptr_t is bigger than int and makes
MSVC happy about this.
Bug: v8:9183
Change-Id: I224eff00c1cbcb9a8c9f16eadaec078db7cf16db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601511
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61405}
We see crashes in the wild that we suspect are caused by these changes.
This is a manual revert because of conflicts.
Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering."
This reverts commit b3b7011867.
Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString."
This reverts commit 5758209026.
Revert "[turbofan] Significantly improve ConsString creation performance."
This reverts commit d6a60a0ee1.
Bug: v8:9147
Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60919}
When pointer compression is enabled the [u]intptr_t and double fields are
only kTaggedSize aligned so in order to avoid undefined behavior in C++ code
we have to access these values in an unaligned pointer friendly way although
both x64 and arm64 architectures (where pointer compression is supported)
allow unaligned access.
These changes will be removed once v8:8875 is fixed and all the
kSystemPointerSize fields are properly aligned.
Bug: v8:7703
Change-Id: I4df477cbdeab806303bb4f675d52b61c06342c8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1528996
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60321}
This change significantly improves the performance of string
concatenation in optimized code for the case where the resulting string
is represented as a ConsString. On the relevant test cases we go from
serializeNaive: 10762 ms.
serializeClever: 7813 ms.
serializeConcat: 10271 ms.
to
serializeNaive: 10278 ms.
serializeClever: 5533 ms.
serializeConcat: 10310 ms.
which represents a 30% improvement on the "clever" benchmark, which
tests specifically the ConsString creation performance.
This was accomplished via a couple of different steps, which are briefly
outlined here:
1. The empty_string gets its own map, so that we can easily recognize
and handle it appropriately in the TurboFan type system. This
allows us to express (and assert) that the inputs to NewConsString
are non-empty strings, making sure that TurboFan no longer creates
"crippled ConsStrings" with empty left or right hand sides.
2. Further split the existing String types in TurboFan to be able to
distinguish between OneByte and TwoByte strings on the type system
level. This allows us to avoid having to dynamically lookup the
resulting ConsString map in case of ConsString creation (i.e. when
we know that both input strings are OneByte strings or at least
one of the input strings is TwoByte).
3. We also introduced more finegrained feedback for the Add bytecode
in the interpreter, having it collect feedback about ConsStrings,
specifically ConsOneByteString and ConsTwoByteString. This feedback
can be used by TurboFan to only inline the relevant code for what
was seen so far. This allows us to remove the Octane/Splay specific
magic in JSTypedLowering to detect ConsString creation, and instead
purely rely on the feedback of what was seen so far (also making it
possible to change the semantics of NewConsString to be a low-level
operator, which is only introduced in SimplifiedLowering by looking
at the input types of StringConcat).
4. On top of the before mentioned type and interpreter changes we added
new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
checks.
There are several more improvements that are possible based on this, but
since the change was already quite big, we decided not to put everything
into the first change, but do some follow up tweaks to the type system,
and builtin optimizations later.
Tbr: mstarzinger@chromium.org
Bug: v8:8834, v8:8931, v8:8939, v8:8951
Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60318}
... when pointer compression is enabled and some number of cleanups.
Bug: v8:7703
Change-Id: If7344abf68a1c4d54e4a79d066dc185f25055d7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477737
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60056}
This CL also gives up trying to maintain double and system word
fields at aligned addresses because currently it's not always
maintained (v8:8875) and Torque object definitions do not support
padding fields (v8:8863).
Given that both platforms where pointer compression is going to be
enabled (x64 and arm64) support loading of doubles and full words
from 4-byte aligned addresses we are fine.
Bug: v8:7703
Change-Id: I99fc6da5a0927f4db9b8fb24c7cc0bfc416523bc
Reviewed-on: https://chromium-review.googlesource.com/c/1496974
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60013}
In the early days of Chrome when we used WebKit there was no support for
ASCII strings on the C++ side, so we put a hint onto these two-byte
strings that said "string only contains one byte data", such that
internally in V8 when these were involved in string operations, we could
instead create the *cheaper* one byte strings.
Nowadays Blink properly supports one-byte string representations and
this additional hint only comes with overhead, since we check it in
quite a few places (i.e. on the hot path for string concatenation), plus
we end up consuming more memory due to the additional string maps.
Removing the hint also frees one bit in the InstanceType zoo for
strings.
This alone improves performance on the `bench-dom-serialize.js` test case
by around **3%**.
Tbr: mstarzinger@chromium.org
Bug: v8:6622, v8:8834, v8:8939
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: I0753f2859cee7b5a37b6f0da64d8ec39fcb044ff
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/1498478
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60006}
This cl: https://chromium-review.googlesource.com/c/v8/v8/+/1421077
changed the implementation of SetProperty to infer the language mode.
Language mode is only required when there is an error to decide if we
have to throw an error or not. However we used to compute language mode
eagerly for PropertyCallbackInfo. This causes regressions in some
benchmarks. This cl changes it by deferring it further by computing
it only when it is actually required.
BUG: v8:8580, chromium:925289
Change-Id: Iba70ec5f9bb3deec16414a1ec418b3963f2144f9
Reviewed-on: https://chromium-review.googlesource.com/c/1454608
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59450}
Two uses in the API needed adaptation; all other uses have already
been subsumed by the new implementation (previously known as
NeverReadOnlySpaceObjectPtr, here renamed to NeverReadOnlySpaceObject).
Bug: v8:3770
Change-Id: Idf0e4a98a407b9afea22e8790da34cf017b892a5
Reviewed-on: https://chromium-review.googlesource.com/c/1397671
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58620}
This reverts commit c1bf25bb68.
Reason for revert: We got many regressions:
https://chromeperf.appspot.com/group_report?rev=58157
Original change's description:
> Enable 31bit Smis everywhere
>
> This is a experiment to see how performance is impacted. If we tank
> too much, we can revert this change.
>
> Change-Id: I01be33f5dd78aee6a5beecdc62adbaa6c3850eb1
> Bug: v8:8344
> Reviewed-on: https://chromium-review.googlesource.com/c/1355279
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58157}
TBR=jarin@chromium.org,sigurds@chromium.org,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8344
Change-Id: I407cb99743a08452edcecfc2e945ef98509e8d32
Reviewed-on: https://chromium-review.googlesource.com/c/1375911
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58227}
and update visitors to not look at raw part. This will allow to have effecient
access to embedder data once kTaggedSize is switched to 32-bit value.
Bug: v8:8518
Change-Id: Ia1875a5ac5f3fb85df5c5555b970fd88d9e8d7a4
Reviewed-on: https://chromium-review.googlesource.com/c/1369957
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58185}
This is a experiment to see how performance is impacted. If we tank
too much, we can revert this change.
Change-Id: I01be33f5dd78aee6a5beecdc62adbaa6c3850eb1
Bug: v8:8344
Reviewed-on: https://chromium-review.googlesource.com/c/1355279
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58157}
this will allow to add raw fields to the native context in a pointer compression
friendly way.
This CL also adds a microtask_queue field to native context which will be used
in a follow-up CL.
Bug: v8:8238, v8:7703
Change-Id: I5ecf72dbc52e8261b694551cbc8476f967967723
Reviewed-on: https://chromium-review.googlesource.com/c/1348073
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57744}
and make the slot occupy two tagged words when pointer compression is enabled.
Tbr: bmeurer@chromium.org
Bug: v8:7703
Change-Id: Idcd3385cc7d5299d9bdaf6a69c7bd0591099f0bb
Reviewed-on: https://chromium-review.googlesource.com/c/1346489
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57693}
an abstraction that hides the details about how embedder data fields are
encoded in EmbedderDataArrays and JSObjects.
Bug: v8:7703
Change-Id: Ic9f6d9511bec557c6671aa6488b9545e353f968c
Reviewed-on: https://chromium-review.googlesource.com/c/1344155
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57679}
This CL also disables fast access to the embedder fields when pointer compression is enabled.
Bug: v8:8477, v8:8238
Change-Id: I368bd87184590f8befdc882817497f75f0024569
Reviewed-on: https://chromium-review.googlesource.com/c/1344117
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57659}
for storing embedder data in native context. We can't use FixedArray because
with enabled pointer compression it would not be possible to fit raw aligned
pointer into 32-bits of a tagged value so we will need to store both tagged
and raw data in this array and therefore custom visitor is required.
Bug: v8:7703
Change-Id: Iae23d9aa76c79a572d5f0f1f3c0f924e8e407dd0
Reviewed-on: https://chromium-review.googlesource.com/c/1340295
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57639}
to control how the memory for Isolate object is allocated.
This is the support for pointer-compression friendly heap layout.
Bug: v8:8182
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ida36b81ee22bd865005c394748b62d4c0897d746
Reviewed-on: https://chromium-review.googlesource.com/c/1251548
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57131}
and also move embedder fields from Isolate to IsolateData.
The external memory counter fields are temporarily moved to IsolateData in
order to avoid unexpected Node JS bot failures which happen if the fields
are left in the Heap class.
Bug: v8:8182
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I9d58f235c0ce40e110f595addd03b80b3617aa77
Reviewed-on: https://chromium-review.googlesource.com/c/1278793
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57037}
with internal::Address. This is in preparation for the upcoming
changes to internal::Object. The public API is unchanged, and
there should be no change in behavior either.
Most of the casts newly introduced here will disappear again once
the migration is complete.
Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2990b06a2511ccc5de3f98fd95a805f30ed589ab
Reviewed-on: https://chromium-review.googlesource.com/c/1036612
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56705}
This changes the Name::hash_field and Symbol::flags to uint32_t as
well, so that both Symbols and Strings consume one fewer word on 64-bit
architectures now. More importantly the access to String::length is
always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
on 64-bit with pointer compression), so the access should be faster.
Bug: v8:7065, v8:8171
Change-Id: I1a38f4470d62fbeba2b3bc5fcf4ecdbada7d6b8a
Tbr: ulan@chromium.org, yangguo@chromium.org, ishell@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1224432
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55861}
This reverts commit a03cec2c33.
Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/21320
Original change's description:
> Reland "[objects] Change String::length field to uint32_t."
>
> This is a reland of 1f1eb625a8, the
> breakage on the GCStress bot seems to be unrelated (maybe flushed
> out by this change). We decided to reland to figure out whether it's
> a random flake or really triggered by this particular change.
>
> Original change's description:
> > [objects] Change String::length field to uint32_t.
> >
> > This changes the Name::hash_field and Symbol::flags to uint32_t as
> > well, so that both Symbols and Strings consume one fewer word on 64-bit
> > architectures now. More importantly the access to String::length is
> > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
> > on 64-bit with pointer compression), so the access should be faster.
> >
> > Bug: v8:7065, v8:8171
> > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
> > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
> > Reviewed-on: https://chromium-review.googlesource.com/1221288
> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#55825}
>
> Bug: v8:7065, v8:8171
> Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org, ulan@chromium.org
> Change-Id: I2be24ac018591c04c826e7e8db82e007b738d156
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/1222308
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55838}
TBR=yangguo@chromium.org,tebbi@chromium.org,ishell@chromium.org,bmeurer@chromium.org
Change-Id: Ic741c3d407d4257a8c86b3082b9a19e33dc89215
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7065, v8:8171
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1222368
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55839}
This is a reland of 1f1eb625a8, the
breakage on the GCStress bot seems to be unrelated (maybe flushed
out by this change). We decided to reland to figure out whether it's
a random flake or really triggered by this particular change.
Original change's description:
> [objects] Change String::length field to uint32_t.
>
> This changes the Name::hash_field and Symbol::flags to uint32_t as
> well, so that both Symbols and Strings consume one fewer word on 64-bit
> architectures now. More importantly the access to String::length is
> always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
> on 64-bit with pointer compression), so the access should be faster.
>
> Bug: v8:7065, v8:8171
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
> Reviewed-on: https://chromium-review.googlesource.com/1221288
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55825}
Bug: v8:7065, v8:8171
Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org, ulan@chromium.org
Change-Id: I2be24ac018591c04c826e7e8db82e007b738d156
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1222308
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55838}
This reverts commit df6157ae19.
Reason for revert: trybots didn't rerun :-/
Original change's description:
> Reland "[objects] Change String::length field to uint32_t."
>
> This is a reland of 1f1eb625a8, the
> breakage on the GCStress bot seems to be unrelated (maybe flushed
> out by this change). We decided to reland to figure out whether it's
> a random flake or really triggered by this particular change.
>
> Original change's description:
> > [objects] Change String::length field to uint32_t.
> >
> > This changes the Name::hash_field and Symbol::flags to uint32_t as
> > well, so that both Symbols and Strings consume one fewer word on 64-bit
> > architectures now. More importantly the access to String::length is
> > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
> > on 64-bit with pointer compression), so the access should be faster.
> >
> > Bug: v8:7065, v8:8171
> > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
> > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
> > Reviewed-on: https://chromium-review.googlesource.com/1221288
> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#55825}
>
> Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org
> Bug: v8:7065, v8:8171
> Change-Id: I3c7d0b00abb15fa98ab622f9ecd8602fc798cbc3
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/1221290
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55836}
TBR=ulan@chromium.org,yangguo@chromium.org,tebbi@chromium.org,ishell@chromium.org,bmeurer@chromium.org
Change-Id: Ieaf3be31166abb02e37370ad846c38fa3d114693
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7065, v8:8171
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1222306
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55837}
This is a reland of 1f1eb625a8, the
breakage on the GCStress bot seems to be unrelated (maybe flushed
out by this change). We decided to reland to figure out whether it's
a random flake or really triggered by this particular change.
Original change's description:
> [objects] Change String::length field to uint32_t.
>
> This changes the Name::hash_field and Symbol::flags to uint32_t as
> well, so that both Symbols and Strings consume one fewer word on 64-bit
> architectures now. More importantly the access to String::length is
> always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
> on 64-bit with pointer compression), so the access should be faster.
>
> Bug: v8:7065, v8:8171
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
> Reviewed-on: https://chromium-review.googlesource.com/1221288
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55825}
Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org
Bug: v8:7065, v8:8171
Change-Id: I3c7d0b00abb15fa98ab622f9ecd8602fc798cbc3
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1221290
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55836}
This reverts commit 1f1eb625a8.
Reason for revert: GC Stress failure (https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/21311)
Original change's description:
> [objects] Change String::length field to uint32_t.
>
> This changes the Name::hash_field and Symbol::flags to uint32_t as
> well, so that both Symbols and Strings consume one fewer word on 64-bit
> architectures now. More importantly the access to String::length is
> always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
> on 64-bit with pointer compression), so the access should be faster.
>
> Bug: v8:7065, v8:8171
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
> Reviewed-on: https://chromium-review.googlesource.com/1221288
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55825}
TBR=yangguo@chromium.org,tebbi@chromium.org,ishell@chromium.org,bmeurer@chromium.org
Change-Id: I73f3200902f9d52e5664d48c938e37d9dfb7bce7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7065, v8:8171
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1221706
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55826}
This changes the Name::hash_field and Symbol::flags to uint32_t as
well, so that both Symbols and Strings consume one fewer word on 64-bit
architectures now. More importantly the access to String::length is
always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
on 64-bit with pointer compression), so the access should be faster.
Bug: v8:7065, v8:8171
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
Reviewed-on: https://chromium-review.googlesource.com/1221288
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55825}
Move everything defined in the v8::internal namespace from include/v8.h
into a separate header that can be included by globals.h/checks.h
instead of the whole v8.h.
Also moves V8_EXPORT into v8config.h (so it can be use in the new
v8-internal.h).
Bug: v8:8015
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I22cdc2728d91a94b309a3d030ed06c0f8a06c723
Reviewed-on: https://chromium-review.googlesource.com/1210102
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55707}
