When we enter a method that needs access to the [[HomeObject]]
we allocate a local variable `.home_object` and assign it the
value from the [[HomeObject]] private symbol. Something along
the lines of:
method() {
var .home_object = %ThisFunction()[home_object_symbol];
...
}
BUG=v8:3867, v8:4031
LOG=N
Review URL: https://codereview.chromium.org/1135243004
Cr-Commit-Position: refs/heads/master@{#28644}
Add a finalize incremental marking mode for CollectAllGarbage to finalize incremental marking when incremental marking is in progress, but we want a full gc at a given CollectAllGarbage call site.
Default mode for CollectAllGarbage is finalize incremental marking and perform a full GC.
BUG=
Review URL: https://codereview.chromium.org/1082973003
Cr-Commit-Position: refs/heads/master@{#27831}
The cause was dynamic allocation of an accounting structure used to
create/initialize the type feedback vector, done at the end of the
numbering pass. The solution is to Zone-allocate the structure to
bring it's lifetime in line with the compilation unit.
BUG=
Review URL: https://codereview.chromium.org/1014793003
Cr-Commit-Position: refs/heads/master@{#27241}
A hydrogen code stub is not the best approach because it builds a frame
and doesn't have the technology to discard roots at tail call exits.
Platform-specific stubs provide much better performance at this point.
R=verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/988653003
Cr-Commit-Position: refs/heads/master@{#27235}
We can reduce the number of type feedback vector slots required, and
also reduce IC misses.
Review URL: https://codereview.chromium.org/1001533002
Cr-Commit-Position: refs/heads/master@{#27149}
The first try failed because I needed to make a better distinction
between clearing ICs according to policy at GC time or unconditional
clearing (say, via %ClearFunctionTypeFeedback).
It was also blocked by an issue in super constructor calls.
This fix (https://codereview.chromium.org/892113002/) needs to land
before checking in this CL.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/866493003
Cr-Commit-Position: refs/heads/master@{#26420}
Reason for revert:
Breaks a regression test on linux isloates, and linux with gcc 4.8.
Original issue's description:
> Use a WeakCell in the CallIC type vector.
>
> This allows us to clear the IC on a more sedate schedule, just
> like Load and Store ICs.
>
> R=ulan@chromium.org
> BUG=
>
> Committed: https://crrev.com/bcc79d33ca6d97d9ecfcfcf110a6ea84a0225389
> Cr-Commit-Position: refs/heads/master@{#26332}
TBR=ulan@chromium.org,mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/886663004
Cr-Commit-Position: refs/heads/master@{#26334}
The MISS handler was being called when the receiver was a Smi, instead,
we should recognize the case and use the heap number map.
BUG=
Review URL: https://codereview.chromium.org/854623002
Cr-Commit-Position: refs/heads/master@{#26076}
A FeedbackNexus is the combination of a feedback vector, a slot(s) in
the vector, along with methods to query and manipulate that information
in a type-correct way.
A CallIC will have a CallICNexus, a LoadIC a LoadICNexus, etc.,
reflecting the fact that different types of ICs configure their data
in unique ways.
This CL limits itself to introducing and using the nexus type only for
CallICs. A follow-up will use them for Load and KeyedLoadICs for the
case when the --vector-ics flag is turned on.
The notion of a Nexus is also embedded at the lowest level of the IC
class. This makes sense because more ICs should become vector-based
in the future.
R=ishell@chromium.org
Review URL: https://codereview.chromium.org/683933002
Cr-Commit-Position: refs/heads/master@{#24952}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24952 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
A FeedbackNexus is the combination of a feedback vector, a slot(s) in
the vector, along with methods to query and manipulate that information
in a type-correct way.
A CallIC will have a CallICNexus, a LoadIC a LoadICNexus, etc.,
reflecting the fact that different types of ICs configure their data
in unique ways.
This CL limits itself to introducing and using the nexus type only for
CallICs. A follow-up will use them for Load and KeyedLoadICs for the
case when the --vector-ics flag is turned on.
The notion of a Nexus is also embedded at the lowest level of the IC
class. This makes sense because more ICs should become vector-based
in the future.
This CL is based on https://codereview.chromium.org/679073002/ which
should land first.
BUG=
R=ishell@chromium.org
Review URL: https://codereview.chromium.org/680883004
Cr-Commit-Position: refs/heads/master@{#24945}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24945 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
