This way we can remove them correctly and avoid leaks.
R=mstarzinger@chromium.org, ulan@chromium.org
Bug: v8:8725
Change-Id: I52cbbf34a94171aaeb581b55aecb25311465544d
Reviewed-on: https://chromium-review.googlesource.com/c/1446453
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59266}
Since the improvement of overload resolution (https://crrev.com/c/1304294),
overload resolution of generics doesn't take into account existing
specializations anymore. This means that the issue of infinite recursion
when an overload of Cast for HeapObject is missing doesn't exist anymore.
Thus we can get rid of the CastHeapObject workaround.
Bug: v8:7793
Change-Id: I8442cfb81b78aaa8234bcee673647261c25f9a63
Reviewed-on: https://chromium-review.googlesource.com/c/1448324
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59263}
Multiplication, division, and toString can take a very long
time for large inputs. This patch adds stack checks to each
of these operations so embedders can interrupt them.
Bug: chromium:922032
Change-Id: Idae9d32d6f78a028de4d2ba3abdb79c624f0dca1
Reviewed-on: https://chromium-review.googlesource.com/c/1444913
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59262}
This factors out one part of the "Remove finisher task" CL
(https://crrev.com/c/1400781), which I would like to test in isolation.
R=ahaas@chromium.org
Bug: v8:8423
Change-Id: I7c598f60c4757df8e26508e68da4b3c300a511cb
Reviewed-on: https://chromium-review.googlesource.com/c/1448316
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59256}
(The bug didn't affect any functionality; we just left detached WeakCells in
inconsistent state.)
BUG=v8:8179
Change-Id: I28f6c27532383b94bdfd746db903096f1dc6f1cc
Reviewed-on: https://chromium-review.googlesource.com/c/1447651
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59255}
Previously AccessorAssembler::HandlePolymorphicCase() had 4 versions of
the inner loop unrolled, but we always had to check against the length
after 1 (POLYMORPHIC with name) or 2 (regular POLYMORPHIC) unrolled
iterations anyways, so there's not a lot of benefit to unrolling besides
the potentially better branch prediction in some cases. But that doesn't
seem to be beneficial even in extreme cases (in fact on ARM cores we
might get some benefit from having less code instead), and probably
doesn't justify the additional C++ / generated code.
I used the following extreme micro-benchmark to check the worst case
performance impact:
```js
function test(o, n) {
var result;
for (var i = 0; i < n; ++i) {
result = o.x;
}
return result;
}
const N = 1e8;
const objs = [{x: 0}, {x:1,a:1}, {x:2,b:2}, {x:3,c:3}];
for (var j = 0; j < objs.length; ++j) test(objs[j], N);
console.time('Time');
for (var j = 0; j < objs.length; ++j) test(objs[j], N);
console.timeEnd('Time');
```
Running this with --noopt shows a ~1% performance regression with this
patch on a beefy z840 gLinux workstation, which gives me some confidence
that overall this patch is going to be neutral and maybe beneficial in
case of less powerful ARM cores.
Note to performance sheriffs: This could potentially tank some
performance tests. In that case we may need to revisit the unrolling.
Bug: v8:8562
Change-Id: I731599a7778da1992d981d36022c407ef5c735eb
Reviewed-on: https://chromium-review.googlesource.com/c/1448275
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59252}
This is a reland of c1bf25bb68
Node bot will turn green after github.com/v8/node/pull/89/
has landed.
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}
Bug: v8:8344
Change-Id: I85a6e5c479f1090f50df3df042571227279a0692
Reviewed-on: https://chromium-review.googlesource.com/c/1448314
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59251}
This is a reland of 1e3582b5ae
Original change's description:
> Reland "[builtins] Verify Isolate compatibility with the embedded blob"
>
> This is a reland of b022e825bd
>
> Original change's description:
> > [builtins] Verify Isolate compatibility with the embedded blob
> >
> > Embedded builtins (= the embedded blob) have a few dependencies on the
> > snapshot state. For instance, they require that metadata stored on
> > builtin Code objects as well as the builtins constant table remain
> > unchanged from mksnapshot-time. Embedders may violate these
> > assumptions by accident, e.g. by loading a snapshot generated with
> > different build flags, leading to seemingly unrelated failures later
> > on.
> >
> > This CL introduces an Isolate hash stored in the embedded blob which
> > hashes relevant parts of builtin Code objects and the builtins
> > constant table. It's verified in Isolate::Init in debug builds.
> >
> > Bug: v8:8723
> > Change-Id: Ifc9bdbe6f56ea67d8984f162afa73a3572cfbba8
> > Reviewed-on: https://chromium-review.googlesource.com/c/1442641
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#59177}
>
> Tbr: yangguo@chromium.org,sigurds@chromium.org
> Bug: v8:8723
> Change-Id: I1dd001783f0f1fae21a9809c8639e40f55b8f663
> Reviewed-on: https://chromium-review.googlesource.com/c/1445985
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59236}
Tbr: yangguo@chromium.org,sigurds@chromium.org
Bug: v8:8723
Change-Id: I8e4ae2f09d16b693c1fb814477d8487385046ee4
Reviewed-on: https://chromium-review.googlesource.com/c/1448312
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59250}
This CL revises some of our error messages to be more precise or more
aesthetically appealing.
R=titzer@chromium.org, ahaas@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: chromium:926311
Change-Id: I38eaee09fd37f9b67fdb08bc7b0df64a6eaf96f9
Reviewed-on: https://chromium-review.googlesource.com/c/1445980
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59249}
These allow to write a tagged uncompressed pointer even if pointer
compression is enabled. This is the least intrusive option; once
TurboFan supports pointer compression better, this CL likely
needs to be revised.
Bug: v8:8183
Change-Id: I56451c364b8620f687d8b9deb9553099ba95b928
Reviewed-on: https://chromium-review.googlesource.com/c/1445978
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59247}
In particular, print the reason for returning false (when
FLAG_trace_turbo_inlining is enabled).
Change-Id: I8924562b16612e5030d5870648ff4827d2a0ecc6
Reviewed-on: https://chromium-review.googlesource.com/c/1445981
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59246}
In noembed builds we serialize all builtins as full on-heap code
objects.
Bug: v8:8716
Cq-Include-Trybots: luci.v8.try:v8_linux_noembed_rel_ng
Change-Id: I48f25a12e05a6d8599e5f9c31f9f56f2ebb9f2d6
Reviewed-on: https://chromium-review.googlesource.com/c/1448272
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59244}
movXXXp are replaced with respective movXXXq.
Drive-by cleanup: unified the way we generate movq with other mov instructions.
Bug: v8:8621, v8:8562
Change-Id: I5c65dccf4e460cad5c3cee3dfabfd6ce39abc244
Reviewed-on: https://chromium-review.googlesource.com/c/1446096
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59243}
This reverts commit 1e3582b5ae.
Reason for revert: Still fails nosnap: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/22789
Original change's description:
> Reland "[builtins] Verify Isolate compatibility with the embedded blob"
>
> This is a reland of b022e825bd
>
> Original change's description:
> > [builtins] Verify Isolate compatibility with the embedded blob
> >
> > Embedded builtins (= the embedded blob) have a few dependencies on the
> > snapshot state. For instance, they require that metadata stored on
> > builtin Code objects as well as the builtins constant table remain
> > unchanged from mksnapshot-time. Embedders may violate these
> > assumptions by accident, e.g. by loading a snapshot generated with
> > different build flags, leading to seemingly unrelated failures later
> > on.
> >
> > This CL introduces an Isolate hash stored in the embedded blob which
> > hashes relevant parts of builtin Code objects and the builtins
> > constant table. It's verified in Isolate::Init in debug builds.
> >
> > Bug: v8:8723
> > Change-Id: Ifc9bdbe6f56ea67d8984f162afa73a3572cfbba8
> > Reviewed-on: https://chromium-review.googlesource.com/c/1442641
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#59177}
>
> Tbr: yangguo@chromium.org,sigurds@chromium.org
> Bug: v8:8723
> Change-Id: I1dd001783f0f1fae21a9809c8639e40f55b8f663
> Reviewed-on: https://chromium-review.googlesource.com/c/1445985
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59236}
TBR=yangguo@chromium.org,sigurds@chromium.org,jgruber@chromium.org
Change-Id: If6082452c739d4de44ed70d3c6355f5282684ac1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8723
Reviewed-on: https://chromium-review.googlesource.com/c/1448311
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59241}
This CL fixes a crash when Structs are used as builtin arguments.
R=tebbi@chromium.org
Bug: v8:7793
Change-Id: Ib9488cdd924894dd9a9aa9fe35f57d93894565e2
Reviewed-on: https://chromium-review.googlesource.com/c/1447774
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59238}
1) JSWeakRef and WeakCell targets are HeapObjects (SMIs are no longer used for
signalling cleared / dead JSWeakRefs / WeakCells.) Make this explicit.
2) There's no need to assert that the target of JSWeakRef cannot be undefined
when handled by MarkCompactCollector::ClearJSWeakRefs, since the code handles
undefined just fine. (The removed comment was true though, since this is the only place
which can set the target to undefined. But maybe in the future there's some
other way to clear a JSWeakRef, e.g., explicit API for it.)
BUG=v8:8179
Change-Id: I762c2b4487770712c7538be799dc188943c92587
Reviewed-on: https://chromium-review.googlesource.com/c/1445986
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59237}
This is a reland of b022e825bd
Original change's description:
> [builtins] Verify Isolate compatibility with the embedded blob
>
> Embedded builtins (= the embedded blob) have a few dependencies on the
> snapshot state. For instance, they require that metadata stored on
> builtin Code objects as well as the builtins constant table remain
> unchanged from mksnapshot-time. Embedders may violate these
> assumptions by accident, e.g. by loading a snapshot generated with
> different build flags, leading to seemingly unrelated failures later
> on.
>
> This CL introduces an Isolate hash stored in the embedded blob which
> hashes relevant parts of builtin Code objects and the builtins
> constant table. It's verified in Isolate::Init in debug builds.
>
> Bug: v8:8723
> Change-Id: Ifc9bdbe6f56ea67d8984f162afa73a3572cfbba8
> Reviewed-on: https://chromium-review.googlesource.com/c/1442641
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59177}
Tbr: yangguo@chromium.org,sigurds@chromium.org
Bug: v8:8723
Change-Id: I1dd001783f0f1fae21a9809c8639e40f55b8f663
Reviewed-on: https://chromium-review.googlesource.com/c/1445985
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59236}
I extracted following class member functions to string.cc
* String
* SeqString
* SeqOneByteString
* SeqTwoByteString
* ConsString
* ThinString
* SlicedString
* ExternalString
* FlatStringReader
* ConsStringIterator
Declaration of all above class are in string.h.
This patch makes compile time of objects.cc from 20.6s to 19.2s on Z840 Linux.
Bug: v8:7629
Change-Id: If74b868b3a3d9a1df2887f82e2557da43ad221f0
Reviewed-on: https://chromium-review.googlesource.com/c/1446342
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59235}
The arm64 backend defines registers with a common base `CPURegister` class which
can represent both general purpose and vector registers. We would use it to
define the `RegisterName` function which results in printing all registers with
`xN` when using the --trace-turbo-graph flag:
~~~
[x0|R|f64] = Arm64LdrD : MRR [x7|R|tp] [x5|R|w64]
^^
This is the d0 register, not x0
~~~
We have `Register` and `VRegister` classes to distinguish general purpose
registers from vector registers, use those to define `RegisterName` functions
and print vector registers as `vN` intead:
~~~
[v0|R|f64] = Arm64LdrD : MRR [x7|R|tp] [x5|R|w64]
~~~
Since FloatRegister, DoubleRegister and Simd128Register are typedef of
VRegister, we cannot differentiate them with the current `DEFINE_REGISTER_NAMES`
abstraction. Architecturaly, S, D and Q registers are aliases of V registers so
that's not a problem.
Change-Id: Ic43036117c834070d3311b65c99ad1e24e1f9c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1445990
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#59234}
This reverts commit 595aafeb21.
Reason for revert:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8922824501209195616/+/steps/Mozilla/0/logs/15.8.2.13/0
Original change's description:
> [builtins] [turbofan] Refactor Float64Pow to use single implementation
>
> Remove platform-specific Float64Pow implementations and utils Pow in
> favor of a base::ieee754::pow implementation.
>
> This unifies the implementation of pow for the compiler, wasm, and
> runtime.
>
> Bug: v8:5848, v8:5086
> Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
> Reviewed-on: https://chromium-review.googlesource.com/c/1403018
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59229}
TBR=yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,clemensh@chromium.org,me@gus.host
Change-Id: I266df4b8350cfcebcea8f6063ad75ad962381105
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5848, v8:5086
Reviewed-on: https://chromium-review.googlesource.com/c/1447715
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59232}
Also use the feedback as a hint for the target, because target and
new.target are often the same and we have no way of checking that
in the serializer.
Bug: v8:7790
Change-Id: I9647bf9ab830a76657de400f413fc1cb798a2ade
Reviewed-on: https://chromium-review.googlesource.com/c/1445988
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59230}
Remove platform-specific Float64Pow implementations and utils Pow in
favor of a base::ieee754::pow implementation.
This unifies the implementation of pow for the compiler, wasm, and
runtime.
Bug: v8:5848, v8:5086
Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
Reviewed-on: https://chromium-review.googlesource.com/c/1403018
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59229}
This adds support for handling exceptions between different frames of
one single interpreter activation. Frames are dropped until a local
handler is found. If none is found in the current activation then we
delegate to the existing stack unwinding mechanism to deal with multiple
activations interspersed with non-interpreter stack frames on the actual
machine stack.
R=clemensh@chromium.org
TEST=cctest/test-run-wasm-exceptions
BUG=v8:8091
Change-Id: Ia4abb27ff037bf0d3e3b05721bd3c971ef820e3c
Reviewed-on: https://chromium-review.googlesource.com/c/1445989
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59228}
In particular, test all integrity level transitions properly.
The motivation for this fix was to get rid of the test that introduce {frozen_symbol}
transition while leaving properties configurable and writable. This CL tests each
integrity transition separately, and sets the attributes accordingly.
Bug: v8:8538
Change-Id: I741d87bba1472aec68bf92084e65edc16c1e08d8
Reviewed-on: https://chromium-review.googlesource.com/c/1446097
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59226}
The CompilationState should not be bound to a specific isolate. Hence
it cannot start foreground task. Instead, the callbacks themselves
should do this if they are specific to one Isolate.
R=mstarzinger@chromium.org
Bug: v8:8689, v8:8050
Change-Id: Ic86bba1dd645401b2b284a9f26eec87718b011e1
Reviewed-on: https://chromium-review.googlesource.com/c/1445977
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59225}
loading every test up-front into the processing queue costs about 224MB for a
x64 testsuite run.
This CL eliminates that overhead by utilizing generators and threading.
LoadingProc now loads test after receiving the results of the loaded tests.
R=machenbach@chromium.org
CC=yangguo@chromium.org,sergiyb@chromium.org
Bug: v8:8174,v8:8731
Change-Id: Ifee79c3e213da568f092de0f1623016174e9410c
Reviewed-on: https://chromium-review.googlesource.com/c/1439240
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59223}
The build config inherited from Chromium only enables a subset
of the checks that UBSan supports. We want them all, so this
patch overrides what "is_ubsan" means for V8.
Bug: v8:3770
Change-Id: I1d0a7d994279272f13ff1d4ac9ed235fcbfc0951
Reviewed-on: https://chromium-review.googlesource.com/c/1443502
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59222}
We noticed that almost every call site were loading both files,
the split isn't necessary anymore.
In some message tests, removed the absolute line number to allow future
changes.
Bug: v8:8726
Change-Id: I8527f0a1ecfa685aa01a5e2f5f47ddf1cb13a545
Reviewed-on: https://chromium-review.googlesource.com/c/1446452
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59220}
Now that we generate the embedded blob and off-heap trampolines
directly after builtin generation, the heap should not contain any
remaining references to full on-heap builtin Code objects.
The one exception is the interpreter entry trampoline copy for
profiling. This mechanism was actually broken by canonicalization; we
intended to store a full copy of the IET on the root list, but
serialization replaced it with the canonicalized builtin. This CL
fixes that as a side-effect.
Bug: v8:8716
Change-Id: Ib37c4004560d67de46b1f8ebe75156361134f57d
Reviewed-on: https://chromium-review.googlesource.com/c/1421037
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59219}
Port ad3546ab74
Original Commit Message:
This is an initial step towards clarifying the layout of the
instruction area. As follow-ups, we should remove additional
safepoint and handler table offset parameters, and perhaps alter
Code::safepoint_table_offset (handler_table) semantics to always
contain a real offset and avoid the magic 0 signifying nonexistent
tables.
R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I6c2d3244710f8f3f33bcceb3988e19547f55fba0
Reviewed-on: https://chromium-review.googlesource.com/c/1446138
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59218}
