This patch stores the promise, resolve, reject properties of the
deferred object created by CreateInternalPromiseCapability and
NewPromiseCapability directly on the promise (if the promise hasn't
been fulfilled), otherwise they are stored on the
PromiseReactionJobInfo.
This patch removes the currently unused
CreateInternalPromiseCapability and inlines the call to create the
deferred promise object.
NewPromiseCapability is the only function that works with a deferred.
This patch results in a 8.5% improvement in benchmarks over 5 runs.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2590563003
Cr-Commit-Position: refs/heads/master@{#41991}
Add test as well.
Add regression test for passing uninitialized promises to init hook
BUG=v8:4643
Review-Url: https://codereview.chromium.org/2578173004
Cr-Commit-Position: refs/heads/master@{#41982}
Section 3.2 of the C++ standard states that destructor definitions
implicitly "use" operator delete functions. Therefore, these operator
delete functions must be defined even if they are never called by
user code explicitly.
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#261
gcc allows them to remain as empty definitions. However, not all
compilers allow this. (e.g. xlc on zOS)
This pull request creates definitions which if ever called, result
in an abort.
R=danno@chromium.org,jochen@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2588433002
Cr-Commit-Position: refs/heads/master@{#41981}
We currently use BitcastTaggedToWord only in from the code assemblers to verify the correctness of the operation.
BUG=
Review-Url: https://codereview.chromium.org/2605073002
Cr-Commit-Position: refs/heads/master@{#41979}
In fast-allocate, the path that leverages Add Mem-Imm fails to take
into account that the allocation size may be adjusted by kDoubleSize/2
for alignment. Limit this instruction to 64-bit only.
Also guard PFDs with the proper facility check.
R=jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=
Review-Url: https://codereview.chromium.org/2605063002
Cr-Commit-Position: refs/heads/master@{#41978}
Before this patch, loops in deferred code would defeat the propagation of the
deferred flag, since back edges would usually not come from deferred blocks,
thus stoping the forward propagation of the deferred flag at loop headers. This
patch ensures that back edges are ignored in the deferred propations, properly
placing loops dominated by deferred labels and the code that follows them into
deferred code.
R=epertoso@chromium.org
LOG=N
Review-Url: https://codereview.chromium.org/2606923002
Cr-Commit-Position: refs/heads/master@{#41976}
Instead of loading the address both the limit and top pointers, rely on the
property that the limit pointer is always directly after the top pointer so that
it can be loaded with the limit pointer's address plus a fixed offset.
This generates smaller code and reduces the number of registers required by the
allocation sequence by one.
LOG=N
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2605043002
Cr-Commit-Position: refs/heads/master@{#41975}
Before this patch, Loads generated in the CSA on x64 that have a zero offset
displacement will add a zero to the effective address rather than using an
addressing mode that folds away the zero.
This functionality already exists on ia32, but the port wasn't purely mechanical
so it hadn't been done on x64.
R=epertoso@chromium.org
LOG=N
Review-Url: https://codereview.chromium.org/2602893002
Cr-Commit-Position: refs/heads/master@{#41974}
... and add explicit CallPrologue/CallEpilogue callbacks to CodeAssemblerState instead.
This will allow IntepreterAssembler to use any other helper assembler.
TBR=rmcilroy@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2600183004
Cr-Commit-Position: refs/heads/master@{#41973}
Specifically, don't propage "needs_frame" up through non-deferred -> deferred
block transitions where there are multiple edges from the non-deferred to
deferred code.
LOG=N
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2606893002
Cr-Commit-Position: refs/heads/master@{#41972}
The rest of the cases I found are places where the runtime function
calls some API that takes handles but itself uses HandleScopes
internally where needed.
R=gsathya@chromium.org
BUG=v8:5783
Review-Url: https://codereview.chromium.org/2600993002
Cr-Commit-Position: refs/heads/master@{#41967}
The TF version of this operation was missing a ToObject coercion, so failed to do
@@toStringTag lookups when passed primitive values.
R=franzih@chromium.org
BUG=v8:5780
Review-Url: https://codereview.chromium.org/2597323002
Cr-Commit-Position: refs/heads/master@{#41961}
This syntax was formerly legal per ECMAScript, but has been a
SyntaxError for some time now. V8 deviates from spec in that it
is instead a runtime error; we'd like to know if we can get
away with removing it (at least in sloppy mode) or if the spec
should be changed.
c.f. https://github.com/tc39/ecma262/issues/257#issuecomment-195106880
Also add self to authors file
BUG=v8:4480
Review-Url: https://codereview.chromium.org/2599253002
Cr-Commit-Position: refs/heads/master@{#41960}
This patch moves the creation of the Intl constructors from JavaScript
to C++ in bootstrapper.cc, to match all of the other builtins exposed
to the web.
BUG=v8:5751
Review-Url: https://codereview.chromium.org/2586763002
Cr-Commit-Position: refs/heads/master@{#41959}
Reason for revert:
Issue https://bugs.chromium.org/p/chromium/issues/detail?id=677055 . I'll send out a follow-on reland, as it should still be possible to eliminate the redundant type system.
Original issue's description:
> [intl] Remove redundant type checking system
>
> Previously, the Intl implementation tracked types two ways:
> - In the intl_initialized_marker_symbol
> - In various named properties of the intl_impl_object_symbol value
>
> As far as I can tell, these will never disagree with each other,
> modulo bugs in Intl itself. This patch removes the second type
> checking system.
>
> BUG=v8:5751
>
> Review-Url: https://codereview.chromium.org/2591203002
> Cr-Commit-Position: refs/heads/master@{#41941}
> Committed: 0d5561b64dTBR=yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5751
Review-Url: https://codereview.chromium.org/2601783002
Cr-Commit-Position: refs/heads/master@{#41958}
ECMA 402 v2 made Intl constructors more strict in terms of how they would
initialize objects, refusing to initialize objects which have already
been constructed. However, when Chrome tried to ship these semantics,
we ran into web compatibility issues.
This patch tries to square the circle and implement the simpler v2 object
semantics while including a compatibility workaround to allow objects to
sort of be initialized later, storing the real underlying Intl object
in a symbol-named property.
The new semantics are described in this PR against the ECMA 402 spec:
https://github.com/tc39/ecma402/pull/84
BUG=v8:4360, v8:4870
LOG=Y
Review-Url: https://codereview.chromium.org/2582993002
Cr-Commit-Position: refs/heads/master@{#41943}
