- 31 Jan, 2019 40 commits
-
-
Tobias Tebbi authored
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/1448324Reviewed-by:
Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59263}
-
Jakob Kummerow authored
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}
-
Ben Smith authored
The new names for memory.drop and table.drop are data.drop and elem.drop respectively. See https://github.com/WebAssembly/bulk-memory-operations/issues/23 and https://github.com/WebAssembly/bulk-memory-operations/pull/46. Change-Id: I07aab8448fabe24eb9734dc7dac6f91c570cb553 Reviewed-on: https://chromium-review.googlesource.com/c/1446148 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#59261}
-
Frank Tang authored
Bug: v8:7834 Change-Id: I5eec99773ac6f366ec5850350083379b4978446e Reviewed-on: https://chromium-review.googlesource.com/c/1446334Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#59260}
-
Ben Smith authored
* There are now two indexes for table.copy and memory.copy, one for the source and the one for the destination table/memory. (see https://github.com/WebAssembly/bulk-memory-operations/pull/43) * Reverse the order of the table.init and memory.init indexes, so the segment index is first and the table/memory index is second. (see https://github.com/WebAssembly/bulk-memory-operations/pull/45) Change-Id: I1781edd4200a7b693e3d0814999e6292aafa58d3 Reviewed-on: https://chromium-review.googlesource.com/c/1446149Reviewed-by:
-
Z Duong Nguyen-Huu authored
According to spec https://tc39.github.io/ecma262/#sec-object.assign, https://tc39.github.io/ecma262/#sec-ordinaryownpropertykeys, object.assign should copy symbols last. The current implementation ignores that order. The idea of the fix here is to do iteration twice, one to skip symbol first then one to skip string. Bug: v8:6705 Change-Id: I27a353e0c44a8f7adcf55d7143dd3ce26bea2724 Reviewed-on: https://chromium-review.googlesource.com/c/1432597 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#59258}
-
Deepti Gandluri authored
Change-Id: I62eaed997f4bf590f6cc09f3cb874340e1cd7ac6 Bug: v8:8564 Reviewed-on: https://chromium-review.googlesource.com/c/1447493Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#59257}
-
Clemens Hammacher authored
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/1448316Reviewed-by:
-
Marja Hölttä authored
(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/1447651Reviewed-by:
-
Michael Spang authored
This is no longer necessary after https://chromium-review.googlesource.com/c/chromium/src/+/1427781 This reverts commit 571076ec. Change-Id: Id754864022171fd3da8f7274b5d3b526603337ce Reviewed-on: https://chromium-review.googlesource.com/c/1446136 Commit-Queue: Michael Spang <spang@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#59254}
-
Camillo Bruni authored
Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
-
Benedikt Meurer authored
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/1448275Reviewed-by: -
Sigurd Schneider authored
This is a reland of c1bf25bb 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:
-
Jakob Gruber authored
This is a reland of 1e3582b5 Original change's description: > Reland "[builtins] Verify Isolate compatibility with the embedded blob" > > This is a reland of b022e825 > > 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/1448312Reviewed-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}
-
Clemens Hammacher authored
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/1445980Reviewed-by:
-
Sigurd Schneider authored
1) Ensure 31bit Smis are enabled if pointer compression is. 2) Enable some code for 31bit Smis Bug: v8:8344 Change-Id: Ib1e68ebfcfd49e16d1548879b7670c88dc73449b Reviewed-on: https://chromium-review.googlesource.com/c/1445979 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59248}
-
Sigurd Schneider authored
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:
-
Georg Neis authored
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/1445981Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59246}
-
Igor Sheludko authored
Bug: v8:8621, v8:8562 Change-Id: I79014f92ba95d21b31ff28cb615a01aa00d0d5d6 Reviewed-on: https://chromium-review.googlesource.com/c/1448271 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Jakob Gruber authored
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/1448272Reviewed-by:
-
Igor Sheludko authored
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:
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:8562 Change-Id: I13e566b95785edf788de842b833cb7f5bc2b731d Reviewed-on: https://chromium-review.googlesource.com/c/1447771Reviewed-by:
-
Clemens Hammacher authored
This reverts commit 1e3582b5. 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 b022e825 > > 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/1448311Reviewed-by:
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: I09cc32bbb43c8659805d7d93637d5be7f61e9fd5 Reviewed-on: https://chromium-review.googlesource.com/c/1447711Reviewed-by:
-
Simon Zünd authored
R=tebbi@chromium.org Bug: v8:7793, v8:8562 Change-Id: I783a6d76edd20b73b25cc81395ecadbedd346e8b Reviewed-on: https://chromium-review.googlesource.com/c/1447775Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#59239}
-
Simon Zünd authored
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/1447774Reviewed-by:
-
Marja Hölttä authored
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/1445986Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Jakob Gruber authored
This is a reland of b022e825 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:
-
Takuto Ikuta authored
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/1446342Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
-
Pierre Langlois authored
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/1445990Reviewed-by:
-
Tamer Tas authored
R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org No-Try: True Bug: v8:8174 Change-Id: Ia77a42f3dce741f661f3d7aee3af2237e53ae0f0 Reviewed-on: https://chromium-review.googlesource.com/c/1447713Reviewed-by:
Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by:
-
Georg Neis authored
This reverts commit 595aafeb. 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/1447715Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59232}
-
Tamer Tas authored
R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org No-Try: true Bug: v8:8174,v8:8728,v8:8763 Change-Id: I27faa43e775b4a834a7c2af3ec1407afb71bb06e Reviewed-on: https://chromium-review.googlesource.com/c/1447714 Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
Georg Neis authored
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/1445988Reviewed-by:
-
Clemens Hammacher authored
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:
-
Michael Starzinger authored
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:
-
Tobias Tebbi authored
Change-Id: Iec5d7b2c73b45012d3bc457f0928c7f39afc8815 Reviewed-on: https://chromium-review.googlesource.com/c/1446454 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#59227}
-
Jaroslav Sevcik authored
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/1446097Reviewed-by: -
Clemens Hammacher authored
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}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/5d6f467..f27d150 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/2f02e1f..6fbda1b Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1a9772f..bc2b64b Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/b695155..1131ccb Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/361dfd1..3a06ff3 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I8be0096df86593d061f48d3d2609c1a9a9a6dc19 Reviewed-on: https://chromium-review.googlesource.com/c/1446150Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#59224}
-
