When FLAG_pretenure_call_new is on, we emit mementos on new object creation
in full code, and consume the feedback in crankshaft. A key difference in the
generated code for stubs is the allocation of an additional type vector slot for the
CallNew AST node, which simplifies the CallConstructStub and CallFunctionStub
considerably.
Some performance tuning still needs to be addressed, therefore the flag is off at
this moment, though fully functional. The goal is to remove the flag as soon as
possible, which allows much code deletion (yay).
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/132963012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20076 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Our generic KeyedStoreIC doesn't handle the case when a callback is
set on array elements in the prototype chain of the object, nor do
we recognize that we need to avoid the monomorphic case if these
callbacks exist.
This CL addresses the issue by looking for dictionary elements in
the prototype chain on IC misses and crankshaft element store
instructions. When found, the generic IC is used. The generic IC is
changed to go to the runtime in this case too.
In general, keyed loads are immune from this problem because they
won't return the hole: discovery of the hole goes to the runtime where
the callback will be found in the prototype chain. Double array loads
in crankshaft can return the hole but only if the prototype chain is
unaltered (we will catch such alterations).
Includes the following patch as well (already reviewed by bmeurer):
Performance regression found in test regress-2185-2.js. The problem was
that the bailout method for TransitionAndStoreStub was not performing
the appropriate transition.
(Review URL for the ElementsTransitionAndStoreIC_Miss change:
https://codereview.chromium.org/26911007)
R=danno@chromium.org
Review URL: https://codereview.chromium.org/35413006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17525 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
They make assumptions about elementskind of arrays based on allocation site
feedback. This feedback is highly dependent on mementos, unrooted objects
placed behind arrays in the heap meant to live until the next scavenge.
GcStress does many more gcs than normal, and wrecks havoc with this kind
of test.
BUG=
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/23449042
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
properly when it is called with a function pointer in the type cell,
instead assuming that an AllocationSite object should be present. The
case where this can happen is if the cell is uninitialized, then the
first constructor call made is to the Array function of a different
context. In that case, we'll store the function pointer in the cell,
and then go ahead and call the array constructor stub too. The bug is
fixed by checking for the AllocationSite object map. If not found, the
constructor stub goes forward with a default ElementsKind, just as in
several other cases.
A test in allocation-site-info.js was beefed up to make sure the state
chain described above is traversed.
BUG=
R=hpayer@chromium.org, hpayer@google.com
Review URL: https://codereview.chromium.org/18277006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15555 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Cleanup of LCallNewArray::PrintDataTo() method
* Created HCallNewArray::PrintDataTo()
* Created many more tests in array-constructor-feedback.js
* Removed redundant instructions in
GenerateRecordCallTarget
* Bugfix in CreateArrayDispatchOneArgument: on a call to
new Array(0), we'd like to set the type feedback cell to
a packed elements kind, but we shouldn't do it if the
cell contains the megamorphic sentinel.
* When used from crankshaft, ArrayConstructorStubs can
avoid verifying that the function being called is the
array function from the current native context, relying
instead on the fact that crankshaft issues an
HCheckFunction to protect the constructor call. (this
new minor key is used in LCodeGen::DoCallNewArray(), and
influences code generation in
CodeStubGraphBuilderBase::BuildArrayConstructor()).
* Optimization: the array constructor specialized for
FAST_SMI_ELEMENTS can save some instructions by looking
up the correct map on the passed in constructor, rather
than indexing into the array of cached maps per element
kind.
BUG=
R=danno@chromium.org
Review URL: https://codereview.chromium.org/17091002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15383 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If the runtime is taken for a constructor like "new Array(100000)", where
allocation site info already led to an elements kind of DOUBLE, then the runtime
would fail to transition the array to dictionary mode. Better to recognize this
case and avoid wasting time by following the advice. Furthermore, it offers a
way to recognize that the array should be in dictionary mode (though a future
checkin will capitalize on that).
BUG=
R=danno@chromium.org
Review URL: https://codereview.chromium.org/15993012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14966 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
