This change correctly sets the {CatchPrediction} field in exception
handler tables for bytecode and optimized code. It also adds tests
independent of promise handling for this prediction, to ensure all our
backends are in sync on their prediction.
R=rmcilroy@chromium.org,yangguo@chromium.org
TEST=mjsunit/compiler/debug-catch-prediction
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1690973002
Cr-Commit-Position: refs/heads/master@{#33906}
In the case of a simple fast-mode receiver without fancy properties, we
can just walk over the descriptor array to find all its initial property
names. As long as the map stays the same, we can also use that
descriptor array to figure out how to handle the properties.
This speeds up
https://github.com/kpdecker/six-speed/tree/master/tests/object-assign by
~2x.
BUG=
Review URL: https://codereview.chromium.org/1688953004
Cr-Commit-Position: refs/heads/master@{#33895}
The break location heavily relies on relocation info. This change
abstracts that away. Currently there is only one implementation for
this interface, for JIT code. Future changes will introduce an
implementation to iterate bytecode arrays.
R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1682853003
Cr-Commit-Position: refs/heads/master@{#33869}
Previously, Object.values() and Object.entries() were piggy-backing on
Object.keys(). This meant that they would pre-filter non-enumerable properties,
violating the runtime behaviour of the methods. Unfortunately, this does not
match the current proposal text.
Also incorporates several tests verifying this behaviour based on tests included
in the ChakraCore implementation.
In this reland, the new patch fills up the longer-lasting FixedArray with
`undefined` to avoid the crash in Heap::Verify().
Originally reviewed at https://codereview.chromium.org/1637753004
BUG=v8:4663
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
Review URL: https://codereview.chromium.org/1673673002
Cr-Commit-Position: refs/heads/master@{#33818}
Generally we only care whether the next object is a hidden prototype.
It's simpler to check whether the current object has a hidden prototype
instead of walking to the next prototype and checking its map.
BUG=
Review URL: https://codereview.chromium.org/1675223002
Cr-Commit-Position: refs/heads/master@{#33816}
It's fine to use JS_OBJECT_TYPE for JSIteratorResult and only have a
preallocated initial map for them to avoid unnecessary polymorphism
from generators / builtin iterators. The instance type doesn't
provide any advantage, since we always have to treat JSIteratorResult
objects as regular JSObjects later.
R=yangguo@chromium.orgTBR=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1680513002
Cr-Commit-Position: refs/heads/master@{#33800}
Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.
The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.
BUG=chromium:579009
LOG=Y
Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
Cr-Commit-Position: refs/heads/master@{#33674}
Review URL: https://codereview.chromium.org/1642223003
Cr-Commit-Position: refs/heads/master@{#33798}
Reason for revert:
[Sheriff] Breaks gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/1642
Original issue's description:
> [es7] refactor and fix Object.values() / Object.entries()
>
> Previously, Object.values() and Object.entries() were piggy-backing on
> Object.keys(). This meant that they would pre-filter non-enumerable properties,
> violating the runtime behaviour of the methods. Unfortunately, this does not
> match the current proposal text.
>
> Also incorporates several tests verifying this behaviour based on tests included
> in the ChakraCore implementation.
>
> BUG=v8:4663
> LOG=N
> R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
>
> Committed: https://crrev.com/5c5ccd9d7f8693990d1a9eb26ba3a94f376dcf0b
> Cr-Commit-Position: refs/heads/master@{#33782}
TBR=littledan@chromium.org,adamk@chromium.org,cbruni@chromium.org,rossberg@chromium.org,caitpotter88@gmail.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4663
Review URL: https://codereview.chromium.org/1675663002
Cr-Commit-Position: refs/heads/master@{#33787}
Previously, Object.values() and Object.entries() were piggy-backing on
Object.keys(). This meant that they would pre-filter non-enumerable properties,
violating the runtime behaviour of the methods. Unfortunately, this does not
match the current proposal text.
Also incorporates several tests verifying this behaviour based on tests included
in the ChakraCore implementation.
BUG=v8:4663
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
Review URL: https://codereview.chromium.org/1637753004
Cr-Commit-Position: refs/heads/master@{#33782}
This makes the field in question more generic by renaming it from the
previous "depth" to "data". Pure refactoring, no function change.
R=rmcilroy@chromium.org,yangguo@chromium.org
Review URL: https://codereview.chromium.org/1670983003
Cr-Commit-Position: refs/heads/master@{#33779}
Reason for revert:
Must revert for now due to chromium api natives issues.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}
TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1670813005
Cr-Commit-Position: refs/heads/master@{#33766}
Adds a new runtime function, %DefineDataPropertyInLiteral, which
takes a fifth argument specifying whether the property and value
are syntactically such that the value is a function (or class)
literal that should have its name set at runtime.
The new runtime call also allows us to eliminate the now-redundant
%DefineClassMethod runtime function.
This should get much less ugly once we can desugar the "dynamic"
part of object literals in the parser (but that work is currently
blocked on having a performant way of desugaring literals).
BUG=v8:3699, v8:3761
LOG=n
Review URL: https://codereview.chromium.org/1626423003
Cr-Commit-Position: refs/heads/master@{#33756}
Note: This is currently only used by yield*, we still need to support it in
other places (such as for-of loops). It can be used manually of course.
(This CL does not touch the full-codegen implementation of yield* because that
code is already dead. The yield* desugaring already supports return and doesn't
need to be touched.)
BUG=v8:3566
LOG=y
Review URL: https://codereview.chromium.org/1639343005
Cr-Commit-Position: refs/heads/master@{#33744}
(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.
TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1668103002
Cr-Commit-Position: refs/heads/master@{#33741}
This implements proper context switching while unwinding the stack due
to an exception being handled in interpreted code. The context under
which the handler is scoped is being preserved in a dedicated register
while the try-block is running. Both, the stack unwinding machinery as
well as the graph builder, restore the context from that register.
R=rmcilroy@chromium.org,bmeurer@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1665833002
Cr-Commit-Position: refs/heads/master@{#33733}
Reason for revert:
Fails a lot of layout tests and blocks the roll. Can be easily reproduced with a local Chromium checkout.
Reference: https://codereview.chromium.org/1652413003/
Original issue's description:
> [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.
>
> Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
> When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
> ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.
>
> The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.
>
> This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.
>
> BUG=chromium:579009
> LOG=Y
>
> Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
> Cr-Commit-Position: refs/heads/master@{#33674}
TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:579009
Review URL: https://codereview.chromium.org/1660263003
Cr-Commit-Position: refs/heads/master@{#33698}
This includes 2 fixes:
1) We didn't properly advance the holder when checking whether
Receiver==Holder, so we'd inadvertently block loading the property if
the first property we find is on the typed array.
2) Reflect.get may cause any object on the prototype chain of the holder
to be the receiver; so we need to recheck for this special state for
each object we perform lookup on.
Review URL: https://codereview.chromium.org/1651913005
Cr-Commit-Position: refs/heads/master@{#33689}
Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.
The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.
This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.
BUG=chromium:579009
LOG=Y
Review URL: https://codereview.chromium.org/1642223003
Cr-Commit-Position: refs/heads/master@{#33674}
String wrappers (new String("foo")) are special objects: their string
characters are accessed like elements, and they also have an elements
backing store. This used to require a bunch of explicit checks like:
if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
/* Handle string characters */
}
// Handle regular elements (for string wrappers and other objects)
obj->GetElementsAccessor()->Whatever(...);
This CL introduces new ElementsKinds for string wrapper objects (one for
fast elements, one for dictionary elements), which allow folding the
special-casing into new StringWrapperElementsAccessors.
No observable change in behavior is intended.
Review URL: https://codereview.chromium.org/1612323003
Cr-Commit-Position: refs/heads/master@{#33616}
This translates the exception handler table attached to a bytecode array
correctly into exceptional projections within the TurboFan graph. We
perform an abstract simulation of handlers that are being entered and
exited by the bytecode iteration to track the correct handler for each
node.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1641723002
Cr-Commit-Position: refs/heads/master@{#33580}
This change adds AbstractCode, which can be either Code or
BytecodeArray, and adds methods to calculate source position based
on that. Also cleans up to use code offsets instead of raw PC
where possible, and consistently uses the offset from instruction
start (as opposed to code object start).
R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1618343002
Cr-Commit-Position: refs/heads/master@{#33579}
The body of a generator function can now refer to the generator's input value via a new
"function.sent" expression. We extend the proposal at
https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md
in the obvious way to also apply to GeneratorResumeAbrupt.
This will enable us to desugar yield*.
The new syntax is behind a new --harmony-function-sent flag.
BUG=v8:4700
LOG=n
Review URL: https://codereview.chromium.org/1620253003
Cr-Commit-Position: refs/heads/master@{#33574}
Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.
Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}
TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1643533003
Cr-Commit-Position: refs/heads/master@{#33556}
This reverts commit 85ba94f28c.
All parallelism can be turned off using --predictable, or --noparallel-compaction.
This patch completely parallelizes
- semispace copy: from space -> to space (within newspace)
- newspace evacuation: newspace -> oldspace
- oldspace compaction: oldspace -> oldspace
Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).
Some low-level details:
- The hard cap on number of tasks has been lifted
- We cache store buffer entries locally before merging them back into the global
StoreBuffer in a finalization phase.
- We cache AllocationSite operations locally before merging them back into the
global pretenuring storage in a finalization phase.
- AllocationSite might be compacted while they would be needed for newspace
evacuation. To mitigate any problems we defer checking allocation sites for
newspace till merging locally buffered data.
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/1640563004
Cr-Commit-Position: refs/heads/master@{#33552}
(Fixed a bug found by nosnap builds.)
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1642613002
Cr-Commit-Position: refs/heads/master@{#33548}
Reason for revert:
[Sheriff] Leads to crashes on all webrtc chromium testers, e.g.:
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/49664
Original issue's description:
> [heap] Parallel newspace evacuation, semispace copy, and compaction \o/
>
> All parallelism can be turned off using --predictable, or --noparallel-compaction.
>
> This patch completely parallelizes
> - semispace copy: from space -> to space (within newspace)
> - newspace evacuation: newspace -> oldspace
> - oldspace compaction: oldspace -> oldspace
>
> Previously newspace has been handled sequentially (semispace copy, newspace
> evacuation) before compacting oldspace in parallel. However, on a high level
> there are no dependencies between those two actions, hence we parallelize them
> altogether. We base the number of evacuation tasks on the overall set of
> to-be-processed pages (newspace + oldspace compaction pages).
>
> Some low-level details:
> - The hard cap on number of tasks has been lifted
> - We cache store buffer entries locally before merging them back into the global
> StoreBuffer in a finalization phase.
> - We cache AllocationSite operations locally before merging them back into the
> global pretenuring storage in a finalization phase.
> - AllocationSite might be compacted while they would be needed for newspace
> evacuation. To mitigate any problems we defer checking allocation sites for
> newspace till merging locally buffered data.
>
> CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
> BUG=chromium:524425
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/8f0fd8c0370ae8c5aab56491b879d7e30c329062
> Cr-Commit-Position: refs/heads/master@{#33523}
TBR=hpayer@chromium.org,ulan@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425
Review URL: https://codereview.chromium.org/1643473002
Cr-Commit-Position: refs/heads/master@{#33539}
All parallelism can be turned off using --predictable, or --noparallel-compaction.
This patch completely parallelizes
- semispace copy: from space -> to space (within newspace)
- newspace evacuation: newspace -> oldspace
- oldspace compaction: oldspace -> oldspace
Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).
Some low-level details:
- The hard cap on number of tasks has been lifted
- We cache store buffer entries locally before merging them back into the global
StoreBuffer in a finalization phase.
- We cache AllocationSite operations locally before merging them back into the
global pretenuring storage in a finalization phase.
- AllocationSite might be compacted while they would be needed for newspace
evacuation. To mitigate any problems we defer checking allocation sites for
newspace till merging locally buffered data.
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/1577853007
Cr-Commit-Position: refs/heads/master@{#33523}
This replace HeapType with a dedicated class that implements just what we need for field type tracking. In the next CL, I plan to remove FieldType::Iterator because FieldType can iterate over at most one map.
The ultimate plan is to get rid of templates in types.(h|cc) and remove type-inl.h.
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1636013002
Cr-Commit-Position: refs/heads/master@{#33521}
Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}
TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1632993003
Cr-Commit-Position: refs/heads/master@{#33520}
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1563213002
Cr-Commit-Position: refs/heads/master@{#33518}
Rename IntepreterExceptionEntryHandler builtin to InterpreterEnterBytecodeDispatch
and use it as the return address when building interpreter frames during deopt.
This ensures that we restart execution of the outer frame at the correct
bytecode.
BUG=v8:4280,v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1633633002
Cr-Commit-Position: refs/heads/master@{#33512}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
Cr-Commit-Position: refs/heads/master@{#33438}
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33461}
Reason for revert:
let me quickly revert the revert, wut?
Goal: my CL should not be in the tree!
Original issue's description:
> Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )
>
> Reason for revert:
> the deopt issues have been taken care of by benedikt
>
> Original issue's description:
> > Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
> >
> > Reason for revert:
> > tanks for-in significantly
> >
> > Original issue's description:
> > > [runtime] Do not use the enum-cache for keys retrieval.
> > >
> > > Currently we fail to properly handle shadowed properties. If the
> > > receiver defines a non-enumerable property that reappears on the
> > > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > > By extending the KeyAccumulator to track non-enumerable properties
> > > we can now properly filter them out when seeing them further up in
> > > the prototype-chain.
> > >
> > > BUG=v8:705
> > > LOG=y
> > >
> > > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > > Cr-Commit-Position: refs/heads/master@{#33405}
> >
> > TBR=jkummerow@chromium.org,bmeurer@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=v8:705
> > LOG=n
> >
> > Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> > Cr-Commit-Position: refs/heads/master@{#33443}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:705
>
> Committed: https://crrev.com/5569e270eda517b5ea74e3a7676b3230cbe2f7a9
> Cr-Commit-Position: refs/heads/master@{#33458}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1614313003
Cr-Commit-Position: refs/heads/master@{#33459}
Reason for revert:
the deopt issues have been taken care of by benedikt
Original issue's description:
> Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
>
> Reason for revert:
> tanks for-in significantly
>
> Original issue's description:
> > [runtime] Do not use the enum-cache for keys retrieval.
> >
> > Currently we fail to properly handle shadowed properties. If the
> > receiver defines a non-enumerable property that reappears on the
> > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > By extending the KeyAccumulator to track non-enumerable properties
> > we can now properly filter them out when seeing them further up in
> > the prototype-chain.
> >
> > BUG=v8:705
> > LOG=y
> >
> > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > Cr-Commit-Position: refs/heads/master@{#33405}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:705
> LOG=n
>
> Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> Cr-Commit-Position: refs/heads/master@{#33443}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1612413003
Cr-Commit-Position: refs/heads/master@{#33458}
Reason for revert:
[Sheriff] Breaks layout tests. Please fix upstream.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077
Original issue's description:
> Array length reduction should throw in strict mode if it can't delete an element.
>
> When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
>
> Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
>
> This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
>
> BUG=v8:4267
> LOG=Y
>
> Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
> Cr-Commit-Position: refs/heads/master@{#33438}
TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4267
Review URL: https://codereview.chromium.org/1611313003
Cr-Commit-Position: refs/heads/master@{#33444}
Reason for revert:
tanks for-in significantly
Original issue's description:
> [runtime] Do not use the enum-cache for keys retrieval.
>
> Currently we fail to properly handle shadowed properties. If the
> receiver defines a non-enumerable property that reappears on the
> prototype as enumerable it incorrectly shows up in [[Enumerate]].
> By extending the KeyAccumulator to track non-enumerable properties
> we can now properly filter them out when seeing them further up in
> the prototype-chain.
>
> BUG=v8:705
> LOG=y
>
> Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> Cr-Commit-Position: refs/heads/master@{#33405}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:705
LOG=n
Review URL: https://codereview.chromium.org/1619803003
Cr-Commit-Position: refs/heads/master@{#33443}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33438}
We divide character ranges into
- BMP, matched normally.
- non-BMP, matched as alternatives of surrogate pair ranges.
- lone surrogates, matched with lookaround assertion that its indeed lone.
R=erik.corry@gmail.com
BUG=v8:2952
LOG=N
Review URL: https://codereview.chromium.org/1578253005
Cr-Commit-Position: refs/heads/master@{#33432}
This change improves performance for the common case of
Object.getOwnPropertyDescriptor by up 3x-4x, where we just
return a property descriptor object for a regular data or
accessor property.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_chromium_rel_ng
R=yangguo@chromium.org
Committed: https://crrev.com/ffa9e82235b20c523ebb1151c6196bc6232296b9
Cr-Commit-Position: refs/heads/master@{#33398}
Review URL: https://codereview.chromium.org/1607943003
Cr-Commit-Position: refs/heads/master@{#33415}
