- 03 May, 2018 2 commits
-
-
Eric Holk authored
SetPermissions causes memory that was previously reserved but uncommitted to be committed. This could put us over the committed memory limit for the process, causing SetPermissions to fail. In this case, we should report this as an out of memory error rather than a crash. Bug: chromium:838880 Change-Id: I2785aa9f5608fa04196fee2b280e0c6df2f56ca8 Reviewed-on: https://chromium-review.googlesource.com/1040657Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#52928}
-
Sathya Gunasekaran authored
This reverts commit 77aba17a. Reason for revert: broke gc stress bot https://ci.chromium.org/buildbot/client.v8/V8%20Mac64%20GC%20Stress/743 Original change's description: > [heap] Verify that newly allocated MemoryChunks are pre-initialzed with 0. > > Bug: chromium:829771 > Change-Id: I78eab59fded3f41c93ecb3d5d8a30e1bddc4576e > Reviewed-on: https://chromium-review.googlesource.com/1039747 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Hannes Payer <hpayer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52925} TBR=hpayer@chromium.org,mlippautz@chromium.org Change-Id: I3053cb9d052e520dd6a41f54a6c7e1654fa4d1f3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:829771 Reviewed-on: https://chromium-review.googlesource.com/1041245Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#52927}
-
- 02 May, 2018 24 commits
-
-
Deepti Gandluri authored
Bug: v8:6532, v8:7570 Change-Id: Ieca502a6a13449ea65e47fb43f0e3d7cb5a09a7d Reviewed-on: https://chromium-review.googlesource.com/1031176 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52926}
-
Hannes Payer authored
Bug: chromium:829771 Change-Id: I78eab59fded3f41c93ecb3d5d8a30e1bddc4576e Reviewed-on: https://chromium-review.googlesource.com/1039747Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52925}
-
Deepti Gandluri authored
Bug:v8:7510 R=ahaas@chromium.org Change-Id: Id3c6b4ebcb89300c4b886c79f4c688bc18648b06 Reviewed-on: https://chromium-review.googlesource.com/1036650 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52924}
-
Michael Lippautz authored
The tracker needs to maintain the byte length as there is no order guarantee when sweeping pages and the byte length may be a HeapNumber that is stored on a different page. The abstraction for ArrayBuffers is left untouched. We distinguish between the following cases: 1. Regular AB (backing_store and bye_length should be used) 2. AB allocated using kReservation but not part of wasm 3. AB allocated using kReservation and part of wasm In practice, 2. does not exist, but we still maintain "allocation_base" and "allocation_length" which fall back to backing_store and byte_length in this case. The problematic part is that they look like innocent getters on the object but actually refer to different data structures or on-heap objects. Since 2. does not exist, and 3. looks up the bounds in its own tracker, it is fine for ArrayBufferTracker to pass backing_store and tracked byte_length. Bug: v8:7701 Change-Id: Ib89d5fe94fce5cef8e5d8343a5415a3b9ad0deba Reviewed-on: https://chromium-review.googlesource.com/1039385Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#52923}
-
Ali Ijaz Sheikh authored
Change-Id: I3cc0dd01d5e33ca7579a4c0dc8f5e65e6b7c76f4 Reviewed-on: https://chromium-review.googlesource.com/924507Reviewed-by: Fadi Meawad <fmeawad@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> Cr-Commit-Position: refs/heads/master@{#52922}
-
Eric Holk authored
This is a reland of ad221d14 Original change's description: > [wasm] Always enable guard regions on 64-bit platforms > > This change makes full 8 GiB guard regions always enabled on 64-bit > platforms. > > Additionally, since all Wasm memory allocation paths have some form of > guard regions, this removes and simplifies most of the logic around > whether to enable guard regions. > > This is a reland of https://crrev.com/c/985142. > > Bug: v8:7619 > Change-Id: I8bf1f86d6f89fd0bb2144431c7628f15a6b00ba0 > Reviewed-on: https://chromium-review.googlesource.com/996466 > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > Commit-Queue: Eric Holk <eholk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52412} Bug: v8:7619 Change-Id: I0f311305472ca2305ad2fa9163560ff54c1422c2 Reviewed-on: https://chromium-review.googlesource.com/999872 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by: Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#52921}
-
Eric Holk authored
These DCHECKs involve reading and comparing two variables that may be modified on a separate thread. Thus, there is no way to ensure these comparisons happen atomically. This leads to runtime failures that are otherwise benign. The other option would be to take the memory tracker mutex, but this seems unnecessary given that two atomic counters is sufficient and these checks are only used during debug builds. Bug: chromium:838043 Change-Id: I1b87698c46c550bd2d58bfef956b5a07cb2ec52c Reviewed-on: https://chromium-review.googlesource.com/1038886Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#52920}
-
Leszek Swirski authored
This reverts commit 2df5e7a7. Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805 Original change's description: > [parser] Slice the source string where possible > > When internalizing string literals (for quoted strings or property names), > try to create a sliced string of the source string rather than allocating > a copy of the bytes. > > This will not work for string literals that contain escapes (e.g. unicode > escapes), and currently does not support two-byte strings. > > Bug: chromium:818642 > Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980 > Reviewed-on: https://chromium-review.googlesource.com/1010282 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52898} TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1039885 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#52919}
-
jgruber authored
test-serialize/SerializationMemoryStats does not actually create a new Isolate from scratch. Instead, it deserializes from the snapshot and we can simply piggy-back off existing output to measure deserialization time. Bug: v8:6666,v8:7693 Change-Id: I8f709ea834ff7f5e46f7ebfa9b0c35d96095bf26 Reviewed-on: https://chromium-review.googlesource.com/1039585Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52918}
-
Choongwoo Han authored
The first element of a given iterable argument can be a hole. Thus, normalize the first element so that we can correctly format the exception message with "undefined" for a hole element, instead of "NaN". Bug: v8:7715 Change-Id: I62edd09e361ebeebab642bb82db29b73a2c7b193 Reviewed-on: https://chromium-review.googlesource.com/1038951Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52917}
-
jgruber authored
Original CL: https://crrev.com/c/1018468 During code generation, we generate self-references (i.e. references to the Code object currently being generated) as references to a temporary handle. When the final Code object has been allocated, the handle's location is fixed up and RelocInfo iteration fixes up all references embedded in the generated code. This adds support for this mechanism to the builtins constants table builder. CodeObject() is now a new handle pointing to a dedicated self-reference marker in order to distinguish between self-references and references to undefined. In Factory::NewCode, we patch up the constants table. TBR=yangguo@chromium.org,mlippautz@chromium.org Bug: v8:6666 Change-Id: I3fa422c57de99c9851dc7a86394a8387c7c2b397 Reviewed-on: https://chromium-review.googlesource.com/1039366 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52916}
-
Michael Achenbach authored
Bug: chromium:830557 Change-Id: If06a39b5c26c9c736d313c2c06950b800f241423 Reviewed-on: https://chromium-review.googlesource.com/1032750 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#52915}
-
Sigurd Schneider authored
We incorrectly used a TurboFan typer check for {0,10,undefined} on the radix argument on Number.parseInt, which was internally widened to the checking whether radix is in range 0-10 or undefined. This CL introduces two separate checks. Bug: chromium:838766 Change-Id: I5ebfc1c82bad5b9794b4f844e79e4df01f541a83 Reviewed-on: https://chromium-review.googlesource.com/1039197Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#52914}
-
Choongwoo Han authored
Bug: chromium:837939 Change-Id: Iaca2bc5b52f47d8add13ed9b82497a53cb522933 Reviewed-on: https://chromium-review.googlesource.com/1034043Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52913}
-
Clemens Hammacher authored
R=titzer@chromium.org Bug: v8:6600 Change-Id: I2eb914e7558c01d924cb9d39f18e1c3a5f5c72e5 Reviewed-on: https://chromium-review.googlesource.com/1035123Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52912}
-
Marja Hölttä authored
BUG=v8:7490 Change-Id: I2a597eda708b2ea34c9e32e39556159b48591b61 Reviewed-on: https://chromium-review.googlesource.com/1039196Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#52911}
-
Tobias Tebbi authored
Change-Id: I59517bd8e2176b5ec64401d5418d7a4ecb1bcc52 Reviewed-on: https://chromium-review.googlesource.com/1033733 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52910}
-
Benedikt Meurer authored
This fixes a bug where we didn't run before/after hooks for await when the debugger is not active, as reported downstream in https://github.com/nodejs/node/issues/20274 Change-Id: I1948d1884c591418d87ffd1d0ccb2bebf4e908f1 Reviewed-on: https://chromium-review.googlesource.com/1039386 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52909}
-
Marja Hölttä authored
BUG=v8:5402,v8:7570 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I56beb15109a3557ba514e8d17880b1a37a109031 Reviewed-on: https://chromium-review.googlesource.com/1032552Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#52908}
-
Choongwoo Han authored
If we add new properties by assigning JSFunction values, properties array was not changed into a dictionary map. Bug: v8:7461 Change-Id: Ie16f974502d0ba362e3650a409c27cdc5856a373 Reviewed-on: https://chromium-review.googlesource.com/1028110Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#52907}
-
Pierre Langlois authored
In order to keep track of where the return address is stored in each block, the UnwindingInfoWriter needs to know if a block exits the current function. However, we would only mark returns and tail-calls as exists, while we also have kArchDebugAbort, kArchThrowTerminator and kArchDeoptimize. This would lead to assertions when generating the snapshot in debug mode with `v8_perf_prof_unwinding_info = true`. Bug: v8:7660 Change-Id: Iee2ab222251f6922dd21442e12cbb6b56534bf54 Reviewed-on: https://chromium-review.googlesource.com/1019504Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#52906}
-
Clemens Hammacher authored
This is a leftover of the time where the memory size was stored as 64 bit value. Now it is stored as 32 bit value, so no need to truncate. R=ahaas@chromium.org Change-Id: I44a1505ebd564aee53e4c9a7168738fcb855264b Reviewed-on: https://chromium-review.googlesource.com/1034883Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52905}
-
Simon Zünd authored
This CL also adds types to a user and three builtins that make use of CreateArrayIterator. R=petermarshall@chromium.org Bug: v8:7570 Change-Id: I96b647a9a57e825db717b40ecec2340b0a3d367d Reviewed-on: https://chromium-review.googlesource.com/1032779 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52904}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/e4820fb..b5eb49a Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/b7d53a9..0b71401 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/dc11306..5b642ef Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/5ca0a34..de94aab TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I6c3c094116e81f4548ed987067bfe4cdba86abf3 Reviewed-on: https://chromium-review.googlesource.com/1038826 Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#52903}
-
- 01 May, 2018 8 commits
-
-
Kenton Varda authored
In b49206de I changed thread_data_table_ and thread_data_table_mutex_ from static members to regular class member variables. To do this, I only deleted the `static` keyword and left the declarations where they were. This was a little odd in that all of the dynamic class members are declared together in one place, but now these two new members weren't next to the rest. Making it a little bit weirder is the fact that these two new members actually ended up being the first members of the class, since the exsiting dynamic members were declared later. This change merely moves these two members down to the end of the dynamic member variable list, where they probably should have gone. Bug: chromium:837477 Change-Id: If993935cc56c8026bb7331493ed657c42ba06ac7 Reviewed-on: https://chromium-review.googlesource.com/1036478Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52902}
-
Vincent Belliard authored
Bug: v8:6600 Change-Id: Icdb53714f50add1a9e25025c5b7d52b90d071aa5 Reviewed-on: https://chromium-review.googlesource.com/1036939Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Vincent Belliard <vincent.belliard@arm.com> Cr-Commit-Position: refs/heads/master@{#52901}
-
Junliang Yan authored
On s390, size_t is defined to be long unsigned int, while Address is unsigned int. Therefore, GCC is complaining conflicting types for parameter 'T' ('long unsigned int' and 'unsigned int') for the Min function. R=ofrobots@google.com, hpayer@chromium.org, mstarzinger@chromium.org, mlippautz@chromium.org Change-Id: Ib04edebad24da694ccd06ff572ee50d3db7f87ff Reviewed-on: https://chromium-review.googlesource.com/1035542Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#52900}
-
Vincent Belliard authored
Bug: v8:6600 Change-Id: I442a76ffc3bcb5e93a7865eb30740556b18cbd79 Reviewed-on: https://chromium-review.googlesource.com/1033731 Commit-Queue: Vincent Belliard <vincent.belliard@arm.com> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52899}
-
Leszek Swirski authored
When internalizing string literals (for quoted strings or property names), try to create a sliced string of the source string rather than allocating a copy of the bytes. This will not work for string literals that contain escapes (e.g. unicode escapes), and currently does not support two-byte strings. Bug: chromium:818642 Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980 Reviewed-on: https://chromium-review.googlesource.com/1010282Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#52898}
-
Rick Waldron authored
R=binji@chromium.org, franzih@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib6db8ec0b9980399e53e4b39f5c10150ca72f555 Reviewed-on: https://chromium-review.googlesource.com/1033426 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#52897}
-
Takuto Ikuta authored
By specifying empty list in public header, unnecessary build dependency will be removed from generated ninja files. Without this patch, building chrome with -j1000 on goma took 5m18.324s build trace: https://chromium-build-stats.appspot.com/ninja_log/upload/ninja_log.7WrwKlEIthV27EMferothKEZjCxH-pZFA4BSrqUB5yw=.gz/trace.html With this patch, building chrome with -j1000 on goma took 4m55.310s build trace: https://chromium-build-stats.appspot.com/ninja_log/upload/ninja_log.AeodnJ70OlK0PI1FRYndJlvRw1774x4_e3k-j_o0Arc=.gz/trace.html This patch deserializes dependency between v8 and chrome. More detail in GN reference. https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/reference.md#public Bug: chromium:578477 Change-Id: Ia76585e31463d7ea3756b1d5ea30f327801141ef Reviewed-on: https://chromium-review.googlesource.com/1034173 Commit-Queue: Takuto Ikuta <tikuta@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52896}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/725734c..e4820fb Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a4814ec..dc11306 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/ec200e7..5ca0a34 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I5dec0baf971082014f47c9646301f10f6431a53b Reviewed-on: https://chromium-review.googlesource.com/1036253Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#52895}
-
- 30 Apr, 2018 6 commits
-
-
Caitlin Potter authored
The originally checked in regression test (https://chromium-review.googlesource.com/c/v8/v8/+/1034210/3/test/mjsunit/es6/regress/regress-7706.js) didn't actually reproduce the bug. BUG=v8:7706 R=gsathya@chromium.org, bmeurer@chromium.org Change-Id: I991c91d5a7f15419e388cb5133a281cf7f51736a Reviewed-on: https://chromium-review.googlesource.com/1036108Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#52894}
-
Gabriel Charette authored
As discussed @ https://chromium-review.googlesource.com/c/chromium/src/+/957761#message-4ba6c1bf637f91507544efc89a31e3e4dd407715 and again @ https://chromium-review.googlesource.com/c/chromium/src/+/957761#message-6d0430e640c82f2d5463259fecdc7fabf945b958 Get rid of task runners for WorkerThreads API (use case is always a one-off task in which case a static call is fine -- just like in Chromium's base/task_scheduler/post_task.h) Calling into V8Platform* from any worker thread is safe, what was previously unsafe was using an Isolate* from worker threads but Isolate* was dropped from the new worker threads APIs so this is now irrelevant. Bug: chromium:817421 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Idd2dbc081edfbcb8985eeb45eb64ffb2555fcf7c Reviewed-on: https://chromium-review.googlesource.com/978443 Commit-Queue: Gabriel Charette <gab@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52893}
-
Gabriel Charette authored
GetWorkerThreadsTaskRunner() was about to be phased out [1] but v8 r52818 landed ahead of it. Add CallDelayedOnWorkerThread() to the new worker thread API to support this use case before phasing out GetWorkerThreadsTaskRunner() [1] https://chromium-review.googlesource.com/c/v8/v8/+/978443 Implemented it in d8+cctest+default-platform right away to avoid requiring a non-null Isolate* (and yet another transitional API). R=ahaas@chromium.org, kozyatinskiy@chromium.org Bug: chromium:817421 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I2bee08fee08cf15a664d31cc6817e21cebe1d140 Reviewed-on: https://chromium-review.googlesource.com/1033584 Commit-Queue: Gabriel Charette <gab@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52892}
-
Eric Holk authored
A stack overflow can be thrown by JSEntryStub, which means the thread-in-wasm flag will not have the expected value. To accommodate this, we now clear the flag during exceptional returns if it is set. Bug: chromium:834624 Change-Id: I8359af79886ab98dfecc2fb39ca19118b7fa38eb Reviewed-on: https://chromium-review.googlesource.com/1019570Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#52891}
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:7424 Change-Id: I334d0521982e173650da7dd5da0627197dff171b Reviewed-on: https://chromium-review.googlesource.com/1035124 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52890}
-
Michael Starzinger authored
R=ahaas@chromium.org Change-Id: I8db129e18dff445a3650a0d5c14da835aaa262d9 Reviewed-on: https://chromium-review.googlesource.com/1033742 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52889}
-