- 13 Feb, 2019 20 commits
-
-
Jakob Gruber authored
Wasm currently still creates executable memory even in interpreter-only mode, and is thus unsupported in jitless mode. This hides wasm completely, which will help e.g. fuzzers that attempt to run wasm code (and currently crash on the CHECK in AddOwnedCode). Bug: v8:7777,chromium:931068 Change-Id: Iee692cb947d482ba16fb0f4da32490d42d5daef8 Reviewed-on: https://chromium-review.googlesource.com/c/1470124Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59561}
-
Michael Starzinger authored
R=jgruber@chromium.org Change-Id: I5b40819b1a746f16b7b18aac1bba65d83a7e3483 Reviewed-on: https://chromium-review.googlesource.com/c/1470127Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59560}
-
Georg Neis authored
Since that condition doesn't depend on anything other than the SFI, the IsInlineable method is the right place for checking it. This also has the benefit that the condition will get checked earlier so that we might avoid unnecessary work. Bug: v8:7790 Change-Id: Ie92d4b72c6c524c5e8412701b88e88c9d73fa5bd Reviewed-on: https://chromium-review.googlesource.com/c/1470061 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#59559}
-
Nico Weber authored
For macros expanding to function definitions, I removed the spurious ; after macro invocations. For macros expandign to function declarations, I made the ; required and consistently inserted it. No behavior change. Bug: chromium:926235 Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549 Reviewed-on: https://chromium-review.googlesource.com/c/1467545Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59558}
-
Clemens Hammacher authored
This removes most macros from the function body decoder unittest. It makes the {Validate} method (and the new {ExpectValidates} and {ExpectFailure}) templates, to receive the code in different formats. Drive-by: Rename "verify" to "validate". R=titzer@chromium.org Bug: v8:8562 Change-Id: I89e6125b52cf40a9539317bf16189208cd0592ab Reviewed-on: https://chromium-review.googlesource.com/c/1458956Reviewed-by: -
Junliang Yan authored
bug: v8:8828 Change-Id: I271f8cd4282f52fbcc573f6ccbe67b1111f62c7f Reviewed-on: https://chromium-review.googlesource.com/c/1448711 Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
-
Georg Neis authored
...by moving a special case into a separate method. Change-Id: I880768ed6fbb7d29b94588435c9da65b01f07fde Reviewed-on: https://chromium-review.googlesource.com/c/1462960 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Georg Neis authored
Change-Id: I7716dab4d6d0ff582acdffb988a05429bccab2ad Reviewed-on: https://chromium-review.googlesource.com/c/1462006 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Toon Verwaest authored
We should just always get an Object in rather than both Object and Object* where the former is dealt with through operator->. Change-Id: I2d2542f37a357d4c410cc5f07c8e3563e66660b7 Reviewed-on: https://chromium-review.googlesource.com/c/1470104Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59553}
-
Georg Neis authored
They didn't take the new premonomorphic state into account. My bad. Bug: chromium:931424 Change-Id: I74ad1f0f8ce0eb764d63c2a3527e597962baca6d Reviewed-on: https://chromium-review.googlesource.com/c/1470125Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59552}
-
Benedikt Meurer authored
Refactor the CallApiCallback builtin to - pass the context as with other stubs, and - pass holder and call data in registers. This avoids having to place holder and call data onto the stack, and thus makes it possible to easily call the CallApiCallback builtin from other builtins while just forwarding the (stack) arguments. The idea is to use this in the future to optimize the general case of calling into any API method via a FunctionTemplateInfo and doing appropriate security and/or interface checks upfront as necessary (eventually making the HandleApiCall C++ builtin obsolete at some point). Bug: v8:8820, chromium:913553 Change-Id: I10c0065016df4d0c24bac3d46945ea597b65ed02 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/1469821 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Georg Neis authored
...mainly by moving two big chunks into separate methods. Change-Id: I048a8d27c28bc171559190a915616efbebdfe6cc Reviewed-on: https://chromium-review.googlesource.com/c/1462957Reviewed-by:
-
Georg Neis authored
This fixes jumbo builds with enabled v8_postmortem_support. Bug: v8:8838 Change-Id: Idf2efc3b94104ca1921b6de121df1c0aa7f3452c Reviewed-on: https://chromium-review.googlesource.com/c/1470102 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59549}
-
Pierre Langlois authored
Each page has a `live_byte_count_` field in its header and it is always accessed with atomic operations. However, apart from one corner case, this field is only accessed by the main thread so let's remove the atomicity by default. To summarise, this changes the MarkingState accessors in the following way: - IncrementalMarkingState: Accesses of live_byte_count_ are now non-atomic. Concurrent marking uses local maps of live bytes per page so we have exclusive access to the field when using this. - MajorAtomicMarkingState: This accessor does not guarantee exclusive access to live_byte_count_ so we need to keep the access atomic. This is used by the scavenger when migrating an object that was marked black, since marking an object black will implicitly increment the live_byte_count_. Additionally, the live_bytes() and SetLiveBytes() accessor methods were not used so remove them. - MajorNonAtomicMarkingState: Accesses of live_byte_count_ are not actually non-atomic. - MinorNonAtomicMarkingState: The `young_generation_live_byte_count_` field is atomic so we can set the memory order manual to relax accesses. Change-Id: I4c6457843783157ca878540e34ad50878afee20c Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Reviewed-on: https://chromium-review.googlesource.com/c/1456095Reviewed-by:
-
Sigurd Schneider authored
Bug: chromium:930948 Change-Id: I7567fec06ec4bad11e8b8336ac13fdfc225b632c Reviewed-on: https://chromium-review.googlesource.com/c/1466503Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59547}
-
Sigurd Schneider authored
- const return type on Full{,Maybe,Heap}ObjectSlot::operator* - Removed stale friend declarations - Moved a method to the right section Bug: v8:8557 Change-Id: I0bd3efdb96a7d997b4404d3a247bea55b083d611 Reviewed-on: https://chromium-review.googlesource.com/c/1467781Reviewed-by: -
Andrew Comminos authored
Sets an atomic field on each sampler when it requests a sample, to be checked when the SIGPROF handler is executed. A counter is not used since signals may be coalesced. Prior to this change, all samplers attached to an isolate received samples when other samplers sent SIGPROF to the VM thread. This change alters the behaviour of different CpuProfiler instances on the same isolate to be in line with the Windows / Fuchsia behaviour. Bug: v8:8835 Change-Id: I0caaa845b596efc9d8b1cd7716c067d9a6359c57 Reviewed-on: https://chromium-review.googlesource.com/c/1468941 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#59545}
-
Simon Zünd authored
The StackTraceFrame object will be used in a future CL to replace StackFrameInfo as the object returned by the inspector API, as well as the object used in the stack_frame_cache. The object itself is a simple wrapper around a reference to a FrameArray plus an index, as well as a reference to a StackFrameInfo object that will get lazily initialized. This is the first step towards unifying stack trace representation and collection. R=jgruber@chromium.org Bug: v8:8742 Change-Id: Iefc7d734fd274ffd164ddf6f43c226531aa26d4c Reviewed-on: https://chromium-review.googlesource.com/c/1458017 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
-
tzik authored
This updates the type of contexts to NativeContext instead of Context, namely on GetFunctionRealm(), GetCreationContext(), and JSGlobalObject::native_context. They should be semantically NativeContexts, but the return type hides the underlying NativeContext, and causes its user to cast the context to native. Change-Id: I2f234b0df8c2dcaeab25cb543e09d80d12ca7369 Reviewed-on: https://chromium-review.googlesource.com/c/1469541Reviewed-by:
-
Pavel Feldman authored
Drive-by utf8 serialization exposed on StringUtil for inspector protocol. Bug: chromium:929862 Change-Id: I930cd43fef9038471908280f15e65a4edec5c6d1 Reviewed-on: https://chromium-review.googlesource.com/c/1468702 Commit-Queue: Pavel Feldman <pfeldman@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Reviewed-by:
-
- 12 Feb, 2019 20 commits
-
-
Pavel Feldman authored
Bug: chromium:929862 Change-Id: I8c23be1d22f70d1143d570050514c36ecfb30fc7 Reviewed-on: https://chromium-review.googlesource.com/c/1466003Reviewed-by:
-
Matt Gardner authored
This CL reuses the logic to determine if out of bounds loads should be allowed to determine whether in bounds hole loads should be converted to undefined or handled as IC misses. bug: v8:8561 Change-Id: I1da859aba082cf21c67e7202b1e308ac4614b64a Reviewed-on: https://chromium-review.googlesource.com/c/1465182Reviewed-by:
-
Maciej Goszczycki authored
It's unused and hinders separating read-only roots into a shared table. Bug: v8:8562 Change-Id: I4a2889d9be5df877b2f9d11ce5146a091d864cd3 Reviewed-on: https://chromium-review.googlesource.com/c/1466963Reviewed-by:
Dan Elphick <delphick@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#59539}
-
Tamer Tas authored
Using test generators meant that we had to remove the progress indicator since the total number of tests weren't known before-hand. This CL implements a progress indicator using test number estimations. cctest and unittests progress indicator is accurate, however estimating means the progress will terminate over 100% in big test suites and sometimes under 100%. R=machenbach@chromium.org CC=sergiyb@chromium.org,yangguo@chromium.org Bug: v8:8769 Change-Id: I40ca5b40f9b1223376d33707f0945900ea98cea3 Reviewed-on: https://chromium-review.googlesource.com/c/1460471 Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#59538}
-
Michael Achenbach authored
NOTRY=true TBR=sergiyb@chromium.org Change-Id: Iaff2d456af6e6494c725efa60cbdc9895201bef5 Reviewed-on: https://chromium-review.googlesource.com/c/1466962Reviewed-by:
-
Benedikt Meurer authored
The previous change to JSCallReducer::ReduceCallApiFunction regressed the case a bit where the optimized graph has some knowledge about the receiver already, but the API callback didn't need any receiver checks, as in that case we unnecessarily added a ConvertReceiver node. This change refactors the code to first see if there's information in the graph about the receiver, and only if none is found, introduce the ConvertReceiver node. It also removes the unnecessary context load from the target function, since the API callback doesn't care about the concrete context, and we never inline cross native contexts, so using whatever incoming context we have is perfectly fine (and saves us from unnecessarily materializing the target just to load the native context off of it). Drive-by-fix: Remove bogus comment about CallApiCallbackStub parameters. Bug: v8:8820 Change-Id: Ide1b283d9e448c3f0ae8f2daf4b1ad0202eae09e Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/1466881 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59536}
-
Tamer Tas authored
Testrunner test-suite doesn't have automated tests for the Fuzzer. A significant change for the testrunner may break the fuzzers. We don't have a way to catch even the syntax errors for the fuzzer before landing CLs. This CL creates a rudimentary test-suite that runs the fuzzer without any tests to see if APIs still work as intended. R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org No-Try: true Bug: v8:8763 Change-Id: Ib4519ca093de2af5279964edd164cee04aae77a8 Reviewed-on: https://chromium-review.googlesource.com/c/1466301Reviewed-by:
-
Maya Lekova authored
Implemented branching and merging of Environments to facilitate handling of conditional and unconditional jumps in the SerializerForBackgroundCompilation. Added tests and printing helpers for the Environment. The internal structure of the hints was changed to ZoneSet to support avoiding of duplicates. Alternative implementation considerations were documented here: https://docs.google.com/document/d/1vCQYhtFPqXafSMweSnGD8l0TKEIB6cPV5UGMHJtpy8k/edit?ts=5bf7d341#heading=h.jx4br0df5qzm R=neis@chromium.org Bug: v8:7790 Change-Id: Ib929c75ddb7f7fb290a5ca28d4422680a1514a4f Reviewed-on: https://chromium-review.googlesource.com/c/1451847Reviewed-by:
-
Michael Lippautz authored
This is a reland of d8a457cb Original change's description: > [global-handles] Do not clear finalization callback on moving > > Bug: chromium:923361 > Change-Id: Id4a0f6515f6b17cec2732df561c1e82080dc29c8 > Reviewed-on: https://chromium-review.googlesource.com/c/1462963 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59498} Bug: chromium:923361 Tbr: mlippautz@chromium.org Change-Id: I05bbaa05daf07232f5356cb0a71d6d1c959ddadd Reviewed-on: https://chromium-review.googlesource.com/c/1466648Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59533}
-
Georg Neis authored
... as there's no search involved and there are never multiple names. Change-Id: Ice88c4d98195e74f6540926b0a1199df62b42da2 Reviewed-on: https://chromium-review.googlesource.com/c/1466645Reviewed-by:
-
peterwmwong authored
TypedArrayElementsInfo now represents an element's size as a log 2 and typed as uintptr. This simplifies and speeds up (avoids possible HeapNumber allocations) a number of calculations: - Number of Elements (length) -> Byte Length - is now a WordShl - Byte Length -> Number of Elements (length) - is now a WordShr - Testing alignment (byte offset or length) - is now a WordAnd These element/byte length related calculations are encapsulated in TypedArrayElementsInfo as struct methods. This reduces the size of CreateTypedArray by 2.125 KB (24%) on Mac x64.release: - Before: 9,088 - After: 6,896 This improves the performance of the following microbencmarks - TypedArrays-ConstructWithBuffer: ~87% - TypedArrays-SubarrayNoSpecies: ~28% Bug: v8:7161 Change-Id: I2239fd0e0af9d3ad55cd52318088d3c7c913ae44 Reviewed-on: https://chromium-review.googlesource.com/c/1456299 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#59531}
-
Tamer Tas authored
Testrunner runs variants of a test sequentially without taking sharding into account. A slow test with slow variants slows down the whole test run no matter the sharding configuration. This CL implements a test hashing algorithm and variant sharding for test variants. R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org Bug: v8:8174 Change-Id: I15f8c547fa2f361fb6c53bf8d5df055d3df38d3e Reviewed-on: https://chromium-review.googlesource.com/c/1458016 Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
Andreas Haas authored
This CL contains the following changes: (1) Allocate memory for WasmTables in the WasmInstance. - We extend the WasmInstance by a FixedArray which stores references to the WasmTables. (2) Rename the name of the backing store of WasmTables from `functions` to `elements`. - The name `functions` just does not fit anyref tables. (3) Generate code with TurboFan for table.get and table.set. (4) Extend wasm-module-builder.js to be able to generate modules with multiple tables. (5) Add mjsunit tests to test table.get and table.set. R=mstarzinger@chromium.org Bug: v8:7581 Change-Id: I44af4838ee7a37b394841a2f673ecae5734a4d1c Reviewed-on: https://chromium-review.googlesource.com/c/1463519 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: -
Tamer Tas authored
R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org Bug: v8:8728 Change-Id: Ia45bd1f19f97c7c3491b57e6808f2c27643f5521 Reviewed-on: https://chromium-review.googlesource.com/c/1466561Reviewed-by:
-
Mythri Alle authored
This reverts commit d8a457cb. Reason for revert: I suspect that this caused the recent spike in the crashes on Canary. So, speculatively reverting this to see if things improve. More details on this bug: chromium:931181 Original change's description: > [global-handles] Do not clear finalization callback on moving > > Bug: chromium:923361 > Change-Id: Id4a0f6515f6b17cec2732df561c1e82080dc29c8 > Reviewed-on: https://chromium-review.googlesource.com/c/1462963 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59498} TBR=ulan@chromium.org,mlippautz@chromium.org Change-Id: Id4d2f49be2a6a913f51f35db9877c5b098f9e20a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:923361, chromium:931181 Reviewed-on: https://chromium-review.googlesource.com/c/1466646Reviewed-by:
-
Benedikt Meurer authored
When calling API functions (i.e. Blink C++ DOM methods and accessors) directly from TurboFan we currently only optimize that to a fast call via the CallApiCallback builtin when TurboFan is able to find reliable map information about the receiver in the graph. This is usually only the case when the call is preceeded by a monomorphic or polymorphic property access on the receiver, i.e. something like ```js element.hasAttribute("bar"); ``` will work, since the call to the `hasAttribute` method is immediately preceeded by a `CheckMaps(element)` in the monomorphic/polymorphic case. However this no longer works when the responsible LOAD_IC was megamorphic or the method is called via `Function#call()` for example: ```js const hasAttribute = Element.prototype.hasAttribute; // ... hasAttribute.call(element, "bar"); ``` This change allows for more optimizations in two cases: 1. When the method accepts any receiver (i.e. no signature type and no access checks needed), and 2. when we find information about the receiver in the graph, but that information is not reliable. For the first case, when the API method accepts any receiver and doesn't limit it to specific types of receivers (aka no compatible receiver check is required), we just insert a ConvertReceiver receiver and pass the result as both the receiver and the holder to the API callback. For the second case, we lift the current restriction of only supporting reliable, stable receiver map information, because we only need to know two things: a. The Map::constructor field on the root map satisfies the compatible receiver check. b. If the receiver is a JSObject, then the "access check needed" bit is not set (or the API method accepts any receiver). Both of these cannot change with map transitions. So if at some point in the past we knew that this held for a given receiver (by looking into the TurboFan graph), we definitely know that it's still going to hold at any later point. Bug: v8:8820 Change-Id: I2316e8a4e2b3b7560e5c5d2b7d1569ebe1d3a1c8 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/1466562 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: -
Georg Neis authored
R=sigurds@chromium.org Change-Id: Ia6874ba5a705dda3a6f2b971cf50618a2229a40f Reviewed-on: https://chromium-review.googlesource.com/c/1466502Reviewed-by:
-
Georg Neis authored
R=sigurds@chromium.org Change-Id: Ia89018f414f83665e836eb1d1ead036fc5043d0a Reviewed-on: https://chromium-review.googlesource.com/c/1466501Reviewed-by:
-
Ulan Degenbaev authored
Most of the users of InNewSpace actually mean InYoungGeneration. Subsequent CL will remove InNewSpace to avoid confusion. Bug: chromium:852420 Tbr: mlippautz@chromium.org Change-Id: I6234d162d51c215787972e7ada1cd5b804b60fda Reviewed-on: https://chromium-review.googlesource.com/c/1463521Reviewed-by:
-
Georg Neis authored
This avoids confusion with the code that is being generated. R=sigurds@chromium.org Change-Id: Icb5bd417ca8502553af201654cca1419b9eac87d Reviewed-on: https://chromium-review.googlesource.com/c/1462001 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
