Adds support for the LdaGlobal and StaGlobal bytecodes to the
BytecodeGraphBuilder. Also fixes a bug in the context node's parameter
index and start node inputs.
Landed on behalf of rmcilroy.
TBR=bmeuer@chromium.org,mythria@chromium.org
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1449373002
Cr-Commit-Position: refs/heads/master@{#32049}
This CL introduces the following visitors:
1) RecordMigratedSlotVisitor which simplifies MarkCompactCollector::MigrateObject().
2) IteratePointersToFromSpaceVisitor which simplifies Heap::IteratePointersToFromSpace().
3) FindPointersToNewSpaceVisitor which simplifies StoreBuffer::IteratePointersToNewSpace().
These changes make the object's body descriptors the one and only place that knows how to traverse the object.
Review URL: https://codereview.chromium.org/1441453002
Cr-Commit-Position: refs/heads/master@{#31992}
1) Body descriptors moved to their own header files.
2) Missing body descriptors added.
3) Template versions of HeapObject::Iterate*() methods added.
4) Body descriptors support new kind of queries: IsValidSlot(offset) which can be used for invalid slots filtering.
This is a first step towards virtual and static visitors unification and support in-object properties in built-in (sub-)classes.
Review URL: https://codereview.chromium.org/1440243002
Cr-Commit-Position: refs/heads/master@{#31980}
The body descriptor supports different visiting policies: it could visit or skip
the code entry and it could visit or skip next function field.
BUG=v8:4531
LOG=Y
Review URL: https://codereview.chromium.org/1422773007
Cr-Commit-Position: refs/heads/master@{#31915}
Reason for revert: failed tests on a Windows build.
TBR=rossberg,cbruni,neis
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1426943007
Cr-Commit-Position: refs/heads/master@{#31907}
This separates the post-processing step for optimized code maps out of
the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
visit all candidates instead of gathering candidates during marking.
Gathering candidates during marking no longer makes sense, now that the
majority of SharedFunctionInfo objects will hold such an optimized code
map. Also it reduces complexity of the implementation. Also conflating
this mechanism with "code flushing" was confusing.
This reverts commit 7f1fb29faa.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/1418453008
Cr-Commit-Position: refs/heads/master@{#31876}
Reason for revert:
Causes GC-Stress failures.
Original issue's description:
> [heap] Separate out optimized code map processing.
>
> This separates the post-processing step for optimized code maps out of
> the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
> visit all candidates instead of gathering candidates during marking.
>
> Gathering candidates during marking no longer makes sense, now that the
> majority of SharedFunctionInfo objects will hold such an optimized code
> map. Also it reduces complexity of the implementation. Also conflating
> this mechanism with "code flushing" was confusing.
>
> This reverts commit b6644e8491.
>
> R=ulan@chromium.org
>
> Committed: https://crrev.com/bb7a5eb2d89bae25f2b5ecb9515669f0ac73c111
> Cr-Commit-Position: refs/heads/master@{#31836}
TBR=ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1412063012
Cr-Commit-Position: refs/heads/master@{#31837}
This separates the post-processing step for optimized code maps out of
the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
visit all candidates instead of gathering candidates during marking.
Gathering candidates during marking no longer makes sense, now that the
majority of SharedFunctionInfo objects will hold such an optimized code
map. Also it reduces complexity of the implementation. Also conflating
this mechanism with "code flushing" was confusing.
This reverts commit b6644e8491.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/1421903012
Cr-Commit-Position: refs/heads/master@{#31836}
Reason for revert:
Breaks build: https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/3565
Original issue's description:
> [heap] Separate out optimized code map processing.
>
> This separates the post-processing step for optimized code maps out of
> the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
> visit all candidates instead of gathering candidates during marking.
>
> Gathering candidates during marking no longer makes sense, now that the
> majority of SharedFunctionInfo objects will hold such an optimized code
> map. Also it reduces complexity of the implementation. Also conflating
> this mechanism with "code flushing" was confusing.
>
> R=ulan@chromium.org
>
> Committed: https://crrev.com/8ad6168d197dd167235c9d342ec7ce37b0daa88b
> Cr-Commit-Position: refs/heads/master@{#31830}
TBR=ulan@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1434503003
Cr-Commit-Position: refs/heads/master@{#31832}
Port ab84025977
Also:
- Fix big-endian compiler hints BYTE_OFFSET macro.
- Clean up PPC code access to compiler hints -- which required some new
SharedFunctionInfo fields to encapsulate kCompilerHintsSmiTagSize.
Original commit message:
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
R=bmeurer@chromium.org, cbruni@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
LOG=N
BUG=v8:4428
Review URL: https://codereview.chromium.org/1423713014
Cr-Commit-Position: refs/heads/master@{#31831}
This separates the post-processing step for optimized code maps out of
the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
visit all candidates instead of gathering candidates during marking.
Gathering candidates during marking no longer makes sense, now that the
majority of SharedFunctionInfo objects will hold such an optimized code
map. Also it reduces complexity of the implementation. Also conflating
this mechanism with "code flushing" was confusing.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/1426953006
Cr-Commit-Position: refs/heads/master@{#31830}
This removes several methods from JSFunction that just delegate to
SharedFunctionInfo. These methods are especially dangerous when they
hide the fact that they potentially affect all function instances
deriving from the same underlying SharedFunctionInfo.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1417213005
Cr-Commit-Position: refs/heads/master@{#31792}
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
LOG=N
BUG=v8:4428
Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
Cr-Commit-Position: refs/heads/master@{#31786}
Review URL: https://codereview.chromium.org/1418623007
Cr-Commit-Position: refs/heads/master@{#31790}
Reason for revert:
failing build bot
Original issue's description:
> [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor.
>
> The current implementation of classes throws the TypeError at the wrong
> point, after activating a new context when directly calling a class
> constructor. According to the spec, the TypeError has to be thrown
> in the caller context.
>
> LOG=N
> BUG=v8:4428
>
> Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
> Cr-Commit-Position: refs/heads/master@{#31786}
TBR=bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4428
Review URL: https://codereview.chromium.org/1415783006
Cr-Commit-Position: refs/heads/master@{#31787}
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
LOG=N
BUG=v8:4428
Review URL: https://codereview.chromium.org/1418623007
Cr-Commit-Position: refs/heads/master@{#31786}
If the property is a data property on the holder (or does not exist) and is a readonly data property in the receiver, then we must fail.
R=rossberg, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1424233005
Cr-Commit-Position: refs/heads/master@{#31751}
TurboFan is actually able to generate property access to all prototypes
of all primitives, except the special Oddball primitives that have no
wrapper counterparts (namely null and undefined from the ES6 point of
view).
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1409163007
Cr-Commit-Position: refs/heads/master@{#31739}
Original issue's description:
> [es6] Better support for built-ins subclassing.
>
> Create proper initial map for original constructor (new.target) instead of doing prototype
> transition on the base constructor's initial map. This approach fixes in-object slack tracking
> for subclass instances.
> This CL also fixes subclassing from String.
>
> BUG=v8:3101, v8:3330
> LOG=Y
>
> Committed: https://crrev.com/cd5f48302a502154a0106d12e3066bd563c6340c
> Cr-Commit-Position: refs/heads/master@{#31680}
It also fixes typed array map smashing done during typed array initialization.
BUG=v8:3101, v8:3330, v8:4419
LOG=Y
Review URL: https://codereview.chromium.org/1413033006
Cr-Commit-Position: refs/heads/master@{#31701}
