Also remove support for "python macros" as the last
existing one is removed in this patch.
Change-Id: I537d604a0a1c9ca11cd5c195841b9f5a0ec74850
Reviewed-on: https://chromium-review.googlesource.com/540836
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46069}
On an error during {ProcessExports()}, we would just continue
execution, resulting in a DCHECK failure later.
I did not find any tests for exported globals, so I added a few
(including a regression test for the referenced bug).
R=ahaas@chromium.org
BUG=chromium:734295
Change-Id: I35370de934c274f870680c662ef848c72268a7bc
Reviewed-on: https://chromium-review.googlesource.com/539401
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46064}
If one wasm instance imports an exported function of another instance,
we unwrap the js-to-wasm wrapper of the export and use the underlying
code object directly. However, the code object does not keep the wasm
instance alive. It is only connected via a WeakCell.
With this CL, we explicitly store a FixedArray of all wasm instances
from which we imported functions to keep them alive at least as long as
the instance which imports the code.
R=mtrofin@chromium.org, ahaas@chromium.org
BUG=chromium:734345
Change-Id: I8dcfc9a4ea2d791a62d8cb7255039e481c50bdfd
Reviewed-on: https://chromium-review.googlesource.com/539738
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46062}
This patch replaces IterateBlackObject with two functions:
- RecordWrites,
- ProcessBlackAllocatedObject.
The RecordWrites function is a write barrier, and its behaviour depends
on whether the concurrent marking is on or not.
The ProcessBlackAllocatedObject is the same indepenent from the
concurrent marker.
BUG=chromium:694255
Change-Id: I1666371fbdac9b26c6f875b9e1d1751da4ea1960
Reviewed-on: https://chromium-review.googlesource.com/541441
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46060}
This adapts the predicate in question to be geared towards TurboFan now
that Crankshaft is no longer being used. It makes the predicate respect
the --allocation-site-pretenuring flag again in all cases.
R=mlippautz@chromium.org
BUG=v8:6408
Change-Id: Ib2753f70d7904764859a2d91815a675745416239
Reviewed-on: https://chromium-review.googlesource.com/541321
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46058}
Inspector uses only BREAK_POSITION_ALIGNED, no tests pass STATEMENT_ALIGNED. It's exposed only with debugger API but I'm pretty sure that nobody actually uses it and as far as mirrors API is deprecated - it's time to remove it.
R=jgruber@chromium.org
Bug: none
Change-Id: I28d62e145811d3eb6f4d64007c47c51b2ecbaf0f
Reviewed-on: https://chromium-review.googlesource.com/536934
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46056}
AllocationSite objects survive if a page moves within new space. The
intended behavior was to update the count only when they are visited by
the Scavenger the first time, as they would die afterwards.
This fixes that case where we would move a page within new space where
most objects survive. We would unnecessarily update the AllocationSite
in this case.
Bug: chromium:651354
Change-Id: Ife4dd3e7f60320e0050e7c83dfc5457f66e2287c
Reviewed-on: https://chromium-review.googlesource.com/541302
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46052}
This makes sure that the coercion of global import values to numbers
remains non-observable to JavaScript. It allows instantiation failures
to fall back to JavaScript proper without accidentally causing some
side-effect to happen twice. Also coercions might invalidate previous
checks done during linking or throw exceptions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6431
BUG=v8:6431
Change-Id: Ibe2f7a336bc0fb25532d526746ecc802e04bbd5c
Reviewed-on: https://chromium-review.googlesource.com/512544
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46051}
The constructor of WireBytesRef checks that offset+length is still in
the uint32_t range. This CL avoids triggering this check on illegally
size strings.
R=ahaas@chromium.org
BUG=chromium:734246
Change-Id: Iab5c7013aa3e0ac5060bc4733e712a1652679b1a
Reviewed-on: https://chromium-review.googlesource.com/539402
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46050}
https://codereview.chromium.org/2632713003 with workaround for old GCC.
Drive-by: fix unused variable in src/wasm/wasm-js.cc
Bug:chromium:457078
Change-Id: I6c1b65076bae783c31869552bc87d05c28550e26
Reviewed-on: https://chromium-review.googlesource.com/538463
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46049}
This was never legal; the spec only allows '\0' in strict-mode strings or templates
when not followed by a decimal digit. Previously we were only enforcing that it
not be followed by an _octal_ digit.
This was already fixed for numeric literals, but not for escape sequences in strings.
BUG=v8:6504
Review-Url: https://codereview.chromium.org/2950633002
Cr-Commit-Position: refs/heads/master@{#46046}
Especially in wasm, many builtins don't actually need a context
parameter. We currently pass Smi::kZero instead. This CL allows to
generate a CallDescriptor for calling stubs without passing a context,
resulting in reduced compile time and code size, and increased
performance when executing these builtins.
We were calling the ThrowWasm* functions without passing a context
anyway (directly from code-generator-<arch>.h). With this change, we
will also call the StackCheck builtin without passing a (null) context.
This saves two bytes of code in each function plus each loop, and also
slightly reduces compile time (very noisy, but statistically
significant).
Drive-by: Use NoContextConstant instead of SmiConstant(Smi::kZero).
R=mstarzinger@chromium.org, ahaas@chromium.org
Change-Id: If794cc4c262a9cca8d29a68010803c01a2eef4a3
Reviewed-on: https://chromium-review.googlesource.com/541423
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46044}
A follow up will allow inserting slots during GC without emiting fences
Bug: chromium:651354
Change-Id: Ia1d0f88e3658bca31933bdb013db15a5c2ecd849
Reviewed-on: https://chromium-review.googlesource.com/541400
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46042}
Add a new JSCallWithArrayLike operator that is backed by the
CallWithArrayLike builtin, and use that operator for both
Function.prototype.apply and Reflect.apply inlining. Also unify
the handling of JSCallWithArrayLike and JSCallWithSpread in
the JSCallReducer to reduce the copy&paste overhead.
Drive-by-fix: Add a lot of test coverage for Reflect.apply and
Function.prototype.apply in optimized code, especially for some
corner cases, which was missing so far.
BUG=v8:4587,v8:5269
R=petermarshall@chromium.org
Review-Url: https://codereview.chromium.org/2950773002
Cr-Commit-Position: refs/heads/master@{#46041}
Changes the handling of TestResultScopes to allow them to be reused by
logical tests by rewiring instead of using a new TestResultScope.
Also does the following:
- moves some fields about in TestResultScope to reduce it's size
- moves RegisterListFreeEvent to the end of ReleaseRegisters to enable
it to be tail-called.
This increases the allowed depth of logical expressions which the
compiler can handle without overflowing the stack by about 2x on x64.
BUG=chromium:731861
Change-Id: I7733797bec5e52d07eec6332c07e2a886f2bbde1
Reviewed-on: https://chromium-review.googlesource.com/539521
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46039}
We can remove a lot of native code and rely on CallOrConstructVarargs
to do the stack manipulation for us.
This will also take advantage of the fast-path for double arrays in
CallOrConstructDoubleVarargs.
We can also remove Runtime_SpreadIterableFixed because it isn't used
anymore. We just call directly into spread_iterable from CSA.
Bug: v8:6488, chromium:704966
Change-Id: I81a18281f062619851134fff7ce88471566ee3b5
Reviewed-on: https://chromium-review.googlesource.com/535615
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46038}
Previously, Date.toString() and friends were completely
implementation-defined. However, they actually seemed to match
each other's behavior with the exception of how years less than
1000 are formatted. The rough consensus among browsers seemed
to be %04d, so this was standardized at TC39 [1]. V8 previously
used %4d (it was the only one to do so); this patch adopts
the new standard.
[1] 5d4acf3377
Bug: v8:6076
Change-Id: I8c795a4e1b71187ad7c24a1aee8d7d66719a2586
Reviewed-on: https://chromium-review.googlesource.com/536733
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46037}
For each Managed<T> (which is a Foreign), we create a weak global handle
with a finalizer which deletes the referenced C++ object once the
Foreign is dead.
Before calling this finalizer, the garbage collector needs to mark the
referenced object black (i.e. live), because the finalizer might
resurrect it.
Since this is never done for managed objects, we can use the more
lightweight phantom handle semantics, which allows the referenced
object to be garbage collected right away.
However, we can't access the global handle via the WeakCallbackInfo,
because the global handle will already be garbage collected. So we need
to store it explicitly. This is solved by storing the global handle
together with the finalizer.
In order to implement this, ownership of the ManagedObjectFinalizer
is moved from the isolate to the managed object.
R=ulan@chromium.org, mtrofin@chromium.org
BUG=v8:6505, chromium:734345
Change-Id: I94a245df601f70e19355d82439d30099e159231b
Reviewed-on: https://chromium-review.googlesource.com/539578
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46036}
This test checks how much time we spent for generating Debugger.paused notification.
R=machenbach@chromium.org
Bug: chromium:688036
Change-Id: Ie8a52aafe6c8d93401b0b2a90a202ddff7de78ef
Reviewed-on: https://chromium-review.googlesource.com/538584
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46035}
During minor MC new space evacuation we could have two adjacent LABs
sharing a mark bit cell. The DCHECK when observing and changing markbits
of the target needs to reflect that.
Bug: chromium:651354
Change-Id: I737d0f9e3d37dfb1cda3f126d37ed5e7123bedc9
Reviewed-on: https://chromium-review.googlesource.com/541296
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46032}
With the exception for map space we can avoid atomic access at all since
pages are locked.
Map space is different since it contains old to new poitners to
LayoutDescriptors that are concurrently used by other tasks for
iterating objects.
Bug: chromium:651354
Change-Id: If7ed99d21676bad8d2944132fb9696ff4123624d
Reviewed-on: https://chromium-review.googlesource.com/539642
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46031}
This is to help the transition to using CSP as the stack pointer.
It does not make JSSP aligned yet, just makes sure that we only modify
JSSP by a multiple of 16 bytes. To do this, we might need to add a padding
slot above the receiver.
BUG=
Review-Url: https://codereview.chromium.org/2938603002
Cr-Commit-Position: refs/heads/master@{#46030}
It is possible that the foreground task is unable to clear the
scheduled unfinished work, eventually leading to an OOM.
We use either code_range on 64 bit, or the capacity of the code space,
as a heuristic for how much memory to use for compilation.
The change avoids blocking the background threads while we're over
the memory threshold. This is to avoid starving the GC.
Bug: v8:6492, chromium:732010
Change-Id: Ic2647d9fa71af4f8cdd2149a434b107cbed3a6c3
Reviewed-on: https://chromium-review.googlesource.com/540763
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46029}
Python List Comprehension does not need join() (alias of os.path.join).
Change-Id: I9d5a8610d88c35fd4e3cb101bc10b25c3d1dd7cf
Reviewed-on: https://chromium-review.googlesource.com/538453
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Cr-Commit-Position: refs/heads/master@{#46027}
The initial implementation did not work in certain cases.
For example, in the following case 'f' didn't have a shared name while
it should have had an empty shared name:
var f = (function() { return function() { return 42; } }();
The new implementation ensures that all anonymous functions have empty
shared name and if any of them happen to be an object literal property
value or an accessor function or a concise method then such a function
is marked as having no shared name.
Bug: v8:6459
Change-Id: I0f936afce0c152d91b2b41c1dc475a5ed841eca0
Reviewed-on: https://chromium-review.googlesource.com/538666
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46026}
Those sets are to be released on the main thread without concurrent
accesses. Making this explicit will give TSAN a chance to help us once
the surrounding code changes.
Bug:
Change-Id: Ia73754caafbeec385d4c922fb8140e3e64f7378c
Reviewed-on: https://chromium-review.googlesource.com/541375
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46025}
This reverts commit 1835b4b177.
Reason for revert: This has a perf regression, wasn't ready just yet.
Original change's description:
> Revert "Revert "[wasm] Throttle the amount of unfinished work to avoid OOM""
>
> This reverts commit 4ee4918195.
>
> Reason for revert: Fix: in d8, blocking all the bg threads starves the GC.
>
> Original change's description:
> > Revert "[wasm] Throttle the amount of unfinished work to avoid OOM"
> >
> > This reverts commit 1280954d3a.
> >
> > Reason for revert: Speculative, GC stress bots started taking much longer after this change.
> >
> > Original change's description:
> > > [wasm] Throttle the amount of unfinished work to avoid OOM
> > >
> > > It is possible that the foreground task is unable to clear the
> > > scheduled unfinished work, eventually leading to an OOM.
> > >
> > > We use either code_range on 64 bit, or the capacity of the code space,
> > > as a heuristic for how much memory to use for compilation.
> > >
> > > Bug: v8:6492, chromium:732010
> > > Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
> > > Reviewed-on: https://chromium-review.googlesource.com/535017
> > > Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#46017}
> >
> > TBR=bradnelson@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
> >
> > Change-Id: I8883cee7f77667530bc50f91bfb468c485e6f7f2
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Bug: v8:6492, chromium:732010
> > Reviewed-on: https://chromium-review.googlesource.com/540270
> > Reviewed-by: Bill Budge <bbudge@chromium.org>
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46020}
>
> TBR=bradnelson@chromium.org,bbudge@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
>
> Change-Id: I1e7a1d0202c3161f9a7139e8895eebf472473ad3
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6492, chromium:732010
> Reviewed-on: https://chromium-review.googlesource.com/540841
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46022}
TBR=bradnelson@chromium.org,bbudge@chromium.org,mtrofin@chromium.org,mtrofin@google.com,ahaas@chromium.org
Change-Id: Ic1351325173b233be3972ff3c159c035838fa963
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6492, chromium:732010
Reviewed-on: https://chromium-review.googlesource.com/540842
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46023}
This reverts commit 4ee4918195.
Reason for revert: Fix: in d8, blocking all the bg threads starves the GC.
Original change's description:
> Revert "[wasm] Throttle the amount of unfinished work to avoid OOM"
>
> This reverts commit 1280954d3a.
>
> Reason for revert: Speculative, GC stress bots started taking much longer after this change.
>
> Original change's description:
> > [wasm] Throttle the amount of unfinished work to avoid OOM
> >
> > It is possible that the foreground task is unable to clear the
> > scheduled unfinished work, eventually leading to an OOM.
> >
> > We use either code_range on 64 bit, or the capacity of the code space,
> > as a heuristic for how much memory to use for compilation.
> >
> > Bug: v8:6492, chromium:732010
> > Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
> > Reviewed-on: https://chromium-review.googlesource.com/535017
> > Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46017}
>
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
>
> Change-Id: I8883cee7f77667530bc50f91bfb468c485e6f7f2
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6492, chromium:732010
> Reviewed-on: https://chromium-review.googlesource.com/540270
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46020}
TBR=bradnelson@chromium.org,bbudge@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: I1e7a1d0202c3161f9a7139e8895eebf472473ad3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6492, chromium:732010
Reviewed-on: https://chromium-review.googlesource.com/540841
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46022}
