v8/src/feedback-vector.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

737 lines
24 KiB
C
Raw Normal View History

// Copyright 2014 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#ifndef V8_FEEDBACK_VECTOR_H_
#define V8_FEEDBACK_VECTOR_H_
#include <vector>
#include "src/base/logging.h"
#include "src/base/macros.h"
#include "src/elements-kind.h"
#include "src/globals.h"
#include "src/objects/map.h"
#include "src/objects/name.h"
#include "src/type-hints.h"
#include "src/zone/zone-containers.h"
// Has to be the last include (doesn't have include guards):
#include "src/objects/object-macros.h"
namespace v8 {
namespace internal {
enum class FeedbackSlotKind {
// This kind means that the slot points to the middle of other slot
// which occupies more than one feedback vector element.
// There must be no such slots in the system.
kInvalid,
// Sloppy kinds come first, for easy language mode testing.
kStoreGlobalSloppy,
kStoreNamedSloppy,
kStoreKeyedSloppy,
kLastSloppyKind = kStoreKeyedSloppy,
// Strict and language mode unaware kinds.
kCall,
kLoadProperty,
kLoadGlobalNotInsideTypeof,
kLoadGlobalInsideTypeof,
kLoadKeyed,
kStoreGlobalStrict,
kStoreNamedStrict,
kStoreOwnNamed,
kStoreKeyedStrict,
kStoreInArrayLiteral,
kBinaryOp,
kCompareOp,
kStoreDataPropertyInLiteral,
Collect type profile for DevTools Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. For now, has a test that compares the stdout of --type-profile in test/message. We will remove this test when --type-profile is fully integrated in the debugger protocol. Adding the test in test/inspector does not work, because the inspector test itself consists of JavaScript code that would convolute the output and be non-deterministic under stress. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43866}
2017-03-16 15:01:31 +00:00
kTypeProfile,
kCreateClosure,
kLiteral,
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
kForIn,
[turbofan] Introduce InstanceOfIC to collect rhs feedback. This adds a new InstanceOfIC where the TestInstanceOf bytecode collects constant feedback about the right-hand side of instanceof operators, including both JSFunction and JSBoundFunction instances. TurboFan then uses the feedback to optimize instanceof in places where the right-hand side is not a known constant (known to TurboFan). This addresses the odd performance cliff that we see with instanceof in functions with multiple closures. It was discovered as one of the main bottlenecks on the uglify-es test in the web-tooling-benchmark. The uglify-es test (run in separation) is ~18% faster with this change. On the micro-benchmark in the tracking bug we go from instanceofSingleClosure_Const: 69 ms. instanceofSingleClosure_Class: 246 ms. instanceofMultiClosure: 246 ms. instanceofParameter: 246 ms. to instanceofSingleClosure_Const: 70 ms. instanceofSingleClosure_Class: 75 ms. instanceofMultiClosure: 76 ms. instanceofParameter: 73 ms. boosting performance by roughly 3.6x and thus effectively removing the performance cliff around instanceof. Bug: v8:6936, v8:6971 Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e Reviewed-on: https://chromium-review.googlesource.com/730686 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48820}
2017-10-23 09:18:57 +00:00
kInstanceOf,
[runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases As discussed in https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#, this CL introduces a new bytecode (CloneObject), and a new IC type. In this prototype implementation, the type feedback looks like the following: Uninitialized case: { uninitialized_sentinel, uninitialized_sentinel } Monomorphic case: { weak 'source' map, strong 'result' map } Polymorphic case: { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value } Megamorphic case: { megamorphic_sentinel, cleared_Value } In the fast case, Object cloning is done by allocating an object with the saved result map, and a shallow clone of the fast properties from the source object, as well as cloned fast elements from the source object. If at any point the fast case can't be taken, the IC transitions to the slow case and remains there. This prototype CL does not include any TurboFan optimization, and the CloneObject operation is merely reduced to a stub call. It may still be possible to get some further improvements by somehow incorporating compile-time boilerplate elements into the cloned object, or simplifying how the boilerplate elements are inserted into the object. In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/ by about 8x, with substantial improvements over the Babel and ObjectAssign scores. R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org BUG=v8:7611 Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e Reviewed-on: https://chromium-review.googlesource.com/1127472 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54595}
2018-07-20 15:24:04 +00:00
kCloneObject,
kKindsNumber // Last value indicating number of kinds.
};
inline bool IsCallICKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kCall;
}
inline bool IsLoadICKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kLoadProperty;
}
inline bool IsLoadGlobalICKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kLoadGlobalNotInsideTypeof ||
kind == FeedbackSlotKind::kLoadGlobalInsideTypeof;
}
inline bool IsKeyedLoadICKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kLoadKeyed;
}
inline bool IsStoreGlobalICKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kStoreGlobalSloppy ||
kind == FeedbackSlotKind::kStoreGlobalStrict;
}
inline bool IsStoreICKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kStoreNamedSloppy ||
kind == FeedbackSlotKind::kStoreNamedStrict;
}
inline bool IsStoreOwnICKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kStoreOwnNamed;
}
inline bool IsStoreDataPropertyInLiteralKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kStoreDataPropertyInLiteral;
}
inline bool IsKeyedStoreICKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kStoreKeyedSloppy ||
kind == FeedbackSlotKind::kStoreKeyedStrict;
}
inline bool IsStoreInArrayLiteralICKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kStoreInArrayLiteral;
}
inline bool IsGlobalICKind(FeedbackSlotKind kind) {
return IsLoadGlobalICKind(kind) || IsStoreGlobalICKind(kind);
}
inline bool IsTypeProfileKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kTypeProfile;
}
[runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases As discussed in https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#, this CL introduces a new bytecode (CloneObject), and a new IC type. In this prototype implementation, the type feedback looks like the following: Uninitialized case: { uninitialized_sentinel, uninitialized_sentinel } Monomorphic case: { weak 'source' map, strong 'result' map } Polymorphic case: { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value } Megamorphic case: { megamorphic_sentinel, cleared_Value } In the fast case, Object cloning is done by allocating an object with the saved result map, and a shallow clone of the fast properties from the source object, as well as cloned fast elements from the source object. If at any point the fast case can't be taken, the IC transitions to the slow case and remains there. This prototype CL does not include any TurboFan optimization, and the CloneObject operation is merely reduced to a stub call. It may still be possible to get some further improvements by somehow incorporating compile-time boilerplate elements into the cloned object, or simplifying how the boilerplate elements are inserted into the object. In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/ by about 8x, with substantial improvements over the Babel and ObjectAssign scores. R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org BUG=v8:7611 Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e Reviewed-on: https://chromium-review.googlesource.com/1127472 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54595}
2018-07-20 15:24:04 +00:00
inline bool IsCloneObjectKind(FeedbackSlotKind kind) {
return kind == FeedbackSlotKind::kCloneObject;
}
inline TypeofMode GetTypeofModeFromSlotKind(FeedbackSlotKind kind) {
DCHECK(IsLoadGlobalICKind(kind));
return (kind == FeedbackSlotKind::kLoadGlobalInsideTypeof)
? INSIDE_TYPEOF
: NOT_INSIDE_TYPEOF;
}
inline LanguageMode GetLanguageModeFromSlotKind(FeedbackSlotKind kind) {
DCHECK(IsStoreICKind(kind) || IsStoreOwnICKind(kind) ||
IsStoreGlobalICKind(kind) || IsKeyedStoreICKind(kind));
STATIC_ASSERT(FeedbackSlotKind::kStoreGlobalSloppy <=
FeedbackSlotKind::kLastSloppyKind);
STATIC_ASSERT(FeedbackSlotKind::kStoreKeyedSloppy <=
FeedbackSlotKind::kLastSloppyKind);
STATIC_ASSERT(FeedbackSlotKind::kStoreNamedSloppy <=
FeedbackSlotKind::kLastSloppyKind);
return (kind <= FeedbackSlotKind::kLastSloppyKind) ? LanguageMode::kSloppy
: LanguageMode::kStrict;
}
std::ostream& operator<<(std::ostream& os, FeedbackSlotKind kind);
typedef std::vector<MaybeObjectHandle> MaybeObjectHandles;
class FeedbackMetadata;
// A FeedbackVector has a fixed header with:
// - shared function info (which includes feedback metadata)
// - invocation count
// - runtime profiler ticks
// - optimized code cell (weak cell or Smi marker)
// followed by an array of feedback slots, of length determined by the feedback
// metadata.
class FeedbackVector : public HeapObject {
public:
NEVER_READ_ONLY_SPACE
DECL_CAST(FeedbackVector)
inline void ComputeCounts(int* with_type_info, int* generic,
int* vector_ic_count);
inline bool is_empty() const;
inline FeedbackMetadata metadata() const;
// [shared_function_info]: The shared function info for the function with this
// feedback vector.
DECL_ACCESSORS(shared_function_info, SharedFunctionInfo)
// [optimized_code_weak_or_smi]: weak reference to optimized code or a Smi
// marker defining optimization behaviour.
DECL_ACCESSORS(optimized_code_weak_or_smi, MaybeObject)
// [length]: The length of the feedback vector (not including the header, i.e.
// the number of feedback slots).
DECL_INT32_ACCESSORS(length)
// [invocation_count]: The number of times this function has been invoked.
DECL_INT32_ACCESSORS(invocation_count)
// [invocation_count]: The number of times this function has been seen by the
// runtime profiler.
DECL_INT32_ACCESSORS(profiler_ticks)
// [deopt_count]: The number of times this function has deoptimized.
DECL_INT32_ACCESSORS(deopt_count)
inline void clear_invocation_count();
inline void increment_deopt_count();
inline Code optimized_code() const;
inline OptimizationMarker optimization_marker() const;
inline bool has_optimized_code() const;
inline bool has_optimization_marker() const;
void ClearOptimizedCode();
void EvictOptimizedCodeMarkedForDeoptimization(SharedFunctionInfo shared,
const char* reason);
static void SetOptimizedCode(Handle<FeedbackVector> vector,
Handle<Code> code);
void SetOptimizationMarker(OptimizationMarker marker);
// Clears the optimization marker in the feedback vector.
void ClearOptimizationMarker();
// Conversion from a slot to an integer index to the underlying array.
static int GetIndex(FeedbackSlot slot) { return slot.ToInt(); }
// Conversion from an integer index to the underlying array to a slot.
static inline FeedbackSlot ToSlot(int index);
inline MaybeObject Get(FeedbackSlot slot) const;
inline MaybeObject get(int index) const;
inline void Set(FeedbackSlot slot, MaybeObject value,
WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
inline void set(int index, MaybeObject value,
WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
inline void Set(FeedbackSlot slot, Object value,
WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
inline void set(int index, Object value,
WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
// Gives access to raw memory which stores the array's data.
inline MaybeObjectSlot slots_start();
// Returns slot kind for given slot.
FeedbackSlotKind GetKind(FeedbackSlot slot) const;
FeedbackSlot GetTypeProfileSlot() const;
V8_EXPORT_PRIVATE static Handle<FeedbackVector> New(
Isolate* isolate, Handle<SharedFunctionInfo> shared);
#define DEFINE_SLOT_KIND_PREDICATE(Name) \
bool Name(FeedbackSlot slot) const { return Name##Kind(GetKind(slot)); }
DEFINE_SLOT_KIND_PREDICATE(IsCallIC)
DEFINE_SLOT_KIND_PREDICATE(IsGlobalIC)
DEFINE_SLOT_KIND_PREDICATE(IsLoadIC)
DEFINE_SLOT_KIND_PREDICATE(IsLoadGlobalIC)
DEFINE_SLOT_KIND_PREDICATE(IsKeyedLoadIC)
DEFINE_SLOT_KIND_PREDICATE(IsStoreIC)
DEFINE_SLOT_KIND_PREDICATE(IsStoreOwnIC)
DEFINE_SLOT_KIND_PREDICATE(IsStoreGlobalIC)
DEFINE_SLOT_KIND_PREDICATE(IsKeyedStoreIC)
DEFINE_SLOT_KIND_PREDICATE(IsTypeProfile)
#undef DEFINE_SLOT_KIND_PREDICATE
// Returns typeof mode encoded into kind of given slot.
inline TypeofMode GetTypeofMode(FeedbackSlot slot) const {
return GetTypeofModeFromSlotKind(GetKind(slot));
}
// Returns language mode encoded into kind of given slot.
inline LanguageMode GetLanguageMode(FeedbackSlot slot) const {
return GetLanguageModeFromSlotKind(GetKind(slot));
}
static void AssertNoLegacyTypes(MaybeObject object);
DECL_PRINTER(FeedbackVector)
DECL_VERIFIER(FeedbackVector)
void FeedbackSlotPrint(std::ostream& os, FeedbackSlot slot); // NOLINT
// Clears the vector slots. Return true if feedback has changed.
bool ClearSlots(Isolate* isolate);
// The object that indicates an uninitialized cache.
static inline Handle<Symbol> UninitializedSentinel(Isolate* isolate);
[turbofan] Optimize O.p.hasOwnProperty inside for-in. Optimize the common pattern for (var i in o) { if (Object.prototype.hasOwnProperty.call(o, i)) { // do something } } which is part of the guard-for-in style in ESLint (see the documentation at https://eslint.org/docs/rules/guard-for-in for details). This pattern also shows up in React and Ember applications quite a lot (and is tested by the appropriate Speedometer benchmarks, although not dominating those benchmarks, since they spent a lot of time in non-TurboFan'ed code). This improves the forInHasOwnProperty and forInHasOwnPropertySafe micro- benchmarks in v8:6702, which look like this function forInHasOwnProperty(o) { var result = 0; for (var i in o) { if (o.hasOwnProperty(i)) { result += 1; } } return result; } function forInHasOwnPropertySafe(o) { var result = 0; for (var i in o) { if (Object.prototype.hasOwnProperty.call(o, i)) { result += 1; } } return result; } by around 4x and allows for additional optimizations in the future, by also elimiating the megamorphic load when accessing the enumerated properties. This changes the interpreter ForInNext bytecode to collect more precise feedback about the for-in state, which now consists of three individual states: UNINITIALIZED, MEGAMORPHIC and GENERIC. The MEGAMORPHIC state means that the ForInNext has only seen objects with a usable enum cache thus far, whereas GENERIC means that we have seen some slow-mode for..in objects as well. R=jarin@chromium.org Bug: v8:6702 Change-Id: Ibcd75ea9b58c3b4f9219f11bc37eb04a2b985604 Reviewed-on: https://chromium-review.googlesource.com/636964 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47632}
2017-08-28 05:26:15 +00:00
// The object that indicates a generic state.
static inline Handle<Symbol> GenericSentinel(Isolate* isolate);
// The object that indicates a megamorphic state.
static inline Handle<Symbol> MegamorphicSentinel(Isolate* isolate);
// The object that indicates a premonomorphic state.
static inline Handle<Symbol> PremonomorphicSentinel(Isolate* isolate);
// A raw version of the uninitialized sentinel that's safe to read during
// garbage collection (e.g., for patching the cache).
static inline Symbol RawUninitializedSentinel(Isolate* isolate);
// Layout description.
#define FEEDBACK_VECTOR_FIELDS(V) \
/* Header fields. */ \
V(kSharedFunctionInfoOffset, kPointerSize) \
V(kOptimizedCodeOffset, kPointerSize) \
V(kLengthOffset, kInt32Size) \
V(kInvocationCountOffset, kInt32Size) \
V(kProfilerTicksOffset, kInt32Size) \
V(kDeoptCountOffset, kInt32Size) \
V(kUnalignedHeaderSize, 0)
DEFINE_FIELD_OFFSET_CONSTANTS(HeapObject::kHeaderSize, FEEDBACK_VECTOR_FIELDS)
#undef FEEDBACK_VECTOR_FIELDS
static const int kHeaderSize =
RoundUp<kObjectAlignment>(int{kUnalignedHeaderSize});
static const int kFeedbackSlotsOffset = kHeaderSize;
class BodyDescriptor;
// Garbage collection support.
static constexpr int SizeFor(int length) {
return kFeedbackSlotsOffset + length * kPointerSize;
}
private:
static void AddToVectorsForProfilingTools(Isolate* isolate,
Handle<FeedbackVector> vector);
OBJECT_CONSTRUCTORS(FeedbackVector, HeapObject);
};
class V8_EXPORT_PRIVATE FeedbackVectorSpec {
public:
explicit FeedbackVectorSpec(Zone* zone) : slot_kinds_(zone) {
slot_kinds_.reserve(16);
}
int slots() const { return static_cast<int>(slot_kinds_.size()); }
FeedbackSlotKind GetKind(FeedbackSlot slot) const {
return static_cast<FeedbackSlotKind>(slot_kinds_.at(slot.ToInt()));
}
bool HasTypeProfileSlot() const;
// If used, the TypeProfileSlot is always added as the first slot and its
// index is constant. If other slots are added before the TypeProfileSlot,
// this number changes.
static const int kTypeProfileSlotIndex = 0;
FeedbackSlot AddCallICSlot() { return AddSlot(FeedbackSlotKind::kCall); }
FeedbackSlot AddLoadICSlot() {
return AddSlot(FeedbackSlotKind::kLoadProperty);
}
FeedbackSlot AddLoadGlobalICSlot(TypeofMode typeof_mode) {
return AddSlot(typeof_mode == INSIDE_TYPEOF
? FeedbackSlotKind::kLoadGlobalInsideTypeof
: FeedbackSlotKind::kLoadGlobalNotInsideTypeof);
}
FeedbackSlot AddCreateClosureSlot() {
return AddSlot(FeedbackSlotKind::kCreateClosure);
}
FeedbackSlot AddKeyedLoadICSlot() {
return AddSlot(FeedbackSlotKind::kLoadKeyed);
}
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
FeedbackSlotKind GetStoreICSlot(LanguageMode language_mode) {
Revert "[interpreter] Add bytecode for leading array spreads." This reverts commit 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. Reason for revert: Clusterfuzz found something. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303 Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
2018-08-31 11:43:24 +00:00
STATIC_ASSERT(LanguageModeSize == 2);
Reland "[interpreter] Add bytecode for leading array spreads." This is a reland of 1c48d52bb1ee9bb28e146c60eda08cd4afaa5745. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 07:50:48 +00:00
return is_strict(language_mode) ? FeedbackSlotKind::kStoreNamedStrict
: FeedbackSlotKind::kStoreNamedSloppy;
}
FeedbackSlot AddStoreICSlot(LanguageMode language_mode) {
return AddSlot(GetStoreICSlot(language_mode));
}
FeedbackSlot AddStoreOwnICSlot() {
return AddSlot(FeedbackSlotKind::kStoreOwnNamed);
}
FeedbackSlot AddStoreGlobalICSlot(LanguageMode language_mode) {
STATIC_ASSERT(LanguageModeSize == 2);
return AddSlot(is_strict(language_mode)
? FeedbackSlotKind::kStoreGlobalStrict
: FeedbackSlotKind::kStoreGlobalSloppy);
}
FeedbackSlotKind GetKeyedStoreICSlotKind(LanguageMode language_mode) {
STATIC_ASSERT(LanguageModeSize == 2);
return is_strict(language_mode) ? FeedbackSlotKind::kStoreKeyedStrict
: FeedbackSlotKind::kStoreKeyedSloppy;
}
FeedbackSlot AddKeyedStoreICSlot(LanguageMode language_mode) {
return AddSlot(GetKeyedStoreICSlotKind(language_mode));
}
FeedbackSlot AddStoreInArrayLiteralICSlot() {
return AddSlot(FeedbackSlotKind::kStoreInArrayLiteral);
}
FeedbackSlot AddBinaryOpICSlot() {
return AddSlot(FeedbackSlotKind::kBinaryOp);
}
FeedbackSlot AddCompareICSlot() {
return AddSlot(FeedbackSlotKind::kCompareOp);
}
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
FeedbackSlot AddForInSlot() { return AddSlot(FeedbackSlotKind::kForIn); }
[turbofan] Introduce InstanceOfIC to collect rhs feedback. This adds a new InstanceOfIC where the TestInstanceOf bytecode collects constant feedback about the right-hand side of instanceof operators, including both JSFunction and JSBoundFunction instances. TurboFan then uses the feedback to optimize instanceof in places where the right-hand side is not a known constant (known to TurboFan). This addresses the odd performance cliff that we see with instanceof in functions with multiple closures. It was discovered as one of the main bottlenecks on the uglify-es test in the web-tooling-benchmark. The uglify-es test (run in separation) is ~18% faster with this change. On the micro-benchmark in the tracking bug we go from instanceofSingleClosure_Const: 69 ms. instanceofSingleClosure_Class: 246 ms. instanceofMultiClosure: 246 ms. instanceofParameter: 246 ms. to instanceofSingleClosure_Const: 70 ms. instanceofSingleClosure_Class: 75 ms. instanceofMultiClosure: 76 ms. instanceofParameter: 73 ms. boosting performance by roughly 3.6x and thus effectively removing the performance cliff around instanceof. Bug: v8:6936, v8:6971 Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e Reviewed-on: https://chromium-review.googlesource.com/730686 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48820}
2017-10-23 09:18:57 +00:00
FeedbackSlot AddInstanceOfSlot() {
return AddSlot(FeedbackSlotKind::kInstanceOf);
}
FeedbackSlot AddLiteralSlot() { return AddSlot(FeedbackSlotKind::kLiteral); }
FeedbackSlot AddStoreDataPropertyInLiteralICSlot() {
return AddSlot(FeedbackSlotKind::kStoreDataPropertyInLiteral);
}
FeedbackSlot AddTypeProfileSlot();
Collect type profile for DevTools Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. For now, has a test that compares the stdout of --type-profile in test/message. We will remove this test when --type-profile is fully integrated in the debugger protocol. Adding the test in test/inspector does not work, because the inspector test itself consists of JavaScript code that would convolute the output and be non-deterministic under stress. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43866}
2017-03-16 15:01:31 +00:00
[runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases As discussed in https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#, this CL introduces a new bytecode (CloneObject), and a new IC type. In this prototype implementation, the type feedback looks like the following: Uninitialized case: { uninitialized_sentinel, uninitialized_sentinel } Monomorphic case: { weak 'source' map, strong 'result' map } Polymorphic case: { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value } Megamorphic case: { megamorphic_sentinel, cleared_Value } In the fast case, Object cloning is done by allocating an object with the saved result map, and a shallow clone of the fast properties from the source object, as well as cloned fast elements from the source object. If at any point the fast case can't be taken, the IC transitions to the slow case and remains there. This prototype CL does not include any TurboFan optimization, and the CloneObject operation is merely reduced to a stub call. It may still be possible to get some further improvements by somehow incorporating compile-time boilerplate elements into the cloned object, or simplifying how the boilerplate elements are inserted into the object. In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/ by about 8x, with substantial improvements over the Babel and ObjectAssign scores. R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org BUG=v8:7611 Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e Reviewed-on: https://chromium-review.googlesource.com/1127472 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54595}
2018-07-20 15:24:04 +00:00
FeedbackSlot AddCloneObjectSlot() {
return AddSlot(FeedbackSlotKind::kCloneObject);
}
#ifdef OBJECT_PRINT
// For gdb debugging.
void Print();
#endif // OBJECT_PRINT
DECL_PRINTER(FeedbackVectorSpec)
private:
FeedbackSlot AddSlot(FeedbackSlotKind kind);
void append(FeedbackSlotKind kind) {
slot_kinds_.push_back(static_cast<unsigned char>(kind));
}
ZoneVector<unsigned char> slot_kinds_;
friend class SharedFeedbackSlot;
};
// Helper class that creates a feedback slot on-demand.
class SharedFeedbackSlot {
public:
// FeedbackSlot default constructor constructs an invalid slot.
SharedFeedbackSlot(FeedbackVectorSpec* spec, FeedbackSlotKind kind)
: kind_(kind), spec_(spec) {}
FeedbackSlot Get() {
if (slot_.IsInvalid()) slot_ = spec_->AddSlot(kind_);
return slot_;
}
private:
FeedbackSlotKind kind_;
FeedbackSlot slot_;
FeedbackVectorSpec* spec_;
};
// FeedbackMetadata is an array-like object with a slot count (indicating how
// many slots are stored). We save space by packing several slots into an array
// of int32 data. The length is never stored - it is always calculated from
// slot_count. All instances are created through the static New function, and
// the number of slots is static once an instance is created.
class FeedbackMetadata : public HeapObject {
public:
DECL_CAST(FeedbackMetadata)
// The number of slots that this metadata contains. Stored as an int32.
DECL_INT32_ACCESSORS(slot_count)
// Get slot_count using an acquire load.
inline int32_t synchronized_slot_count() const;
// Returns number of feedback vector elements used by given slot kind.
static inline int GetSlotSize(FeedbackSlotKind kind);
bool SpecDiffersFrom(const FeedbackVectorSpec* other_spec) const;
inline bool is_empty() const;
// Returns slot kind for given slot.
FeedbackSlotKind GetKind(FeedbackSlot slot) const;
// If {spec} is null, then it is considered empty.
V8_EXPORT_PRIVATE static Handle<FeedbackMetadata> New(
Isolate* isolate, const FeedbackVectorSpec* spec = nullptr);
DECL_PRINTER(FeedbackMetadata)
DECL_VERIFIER(FeedbackMetadata)
static const char* Kind2String(FeedbackSlotKind kind);
bool HasTypeProfileSlot() const;
Collect type profile for DevTools Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. For now, has a test that compares the stdout of --type-profile in test/message. We will remove this test when --type-profile is fully integrated in the debugger protocol. Adding the test in test/inspector does not work, because the inspector test itself consists of JavaScript code that would convolute the output and be non-deterministic under stress. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43866}
2017-03-16 15:01:31 +00:00
// Garbage collection support.
// This includes any necessary padding at the end of the object for pointer
// size alignment.
static int SizeFor(int slot_count) {
return OBJECT_POINTER_ALIGN(kHeaderSize + length(slot_count) * kInt32Size);
}
static const int kSlotCountOffset = HeapObject::kHeaderSize;
static const int kHeaderSize = kSlotCountOffset + kInt32Size;
class BodyDescriptor;
private:
friend class AccessorAssembler;
// Raw accessors to the encoded slot data.
inline int32_t get(int index) const;
inline void set(int index, int32_t value);
// The number of int32 data fields needed to store {slot_count} slots.
// Does not include any extra padding for pointer size alignment.
static int length(int slot_count) {
return VectorICComputer::word_count(slot_count);
}
inline int length() const;
static const int kFeedbackSlotKindBits = 5;
STATIC_ASSERT(static_cast<int>(FeedbackSlotKind::kKindsNumber) <
(1 << kFeedbackSlotKindBits));
void SetKind(FeedbackSlot slot, FeedbackSlotKind kind);
typedef BitSetComputer<FeedbackSlotKind, kFeedbackSlotKindBits,
kInt32Size * kBitsPerByte, uint32_t>
VectorICComputer;
OBJECT_CONSTRUCTORS(FeedbackMetadata, HeapObject);
};
// Verify that an empty hash field looks like a tagged object, but can't
// possibly be confused with a pointer.
STATIC_ASSERT((Name::kEmptyHashField & kHeapObjectTag) == kHeapObjectTag);
STATIC_ASSERT(Name::kEmptyHashField == 0x3);
// Verify that a set hash field will not look like a tagged object.
STATIC_ASSERT(Name::kHashNotComputedMask == kHeapObjectTag);
class FeedbackMetadataIterator {
public:
explicit FeedbackMetadataIterator(Handle<FeedbackMetadata> metadata)
: metadata_handle_(metadata),
next_slot_(FeedbackSlot(0)),
slot_kind_(FeedbackSlotKind::kInvalid) {}
explicit FeedbackMetadataIterator(FeedbackMetadata metadata)
: metadata_(metadata),
next_slot_(FeedbackSlot(0)),
slot_kind_(FeedbackSlotKind::kInvalid) {}
inline bool HasNext() const;
inline FeedbackSlot Next();
// Returns slot kind of the last slot returned by Next().
FeedbackSlotKind kind() const {
DCHECK_NE(FeedbackSlotKind::kInvalid, slot_kind_);
DCHECK_NE(FeedbackSlotKind::kKindsNumber, slot_kind_);
return slot_kind_;
}
// Returns entry size of the last slot returned by Next().
inline int entry_size() const;
private:
FeedbackMetadata metadata() const {
return !metadata_handle_.is_null() ? *metadata_handle_ : metadata_;
}
// The reason for having a handle and a raw pointer to the meta data is
// to have a single iterator implementation for both "handlified" and raw
// pointer use cases.
Handle<FeedbackMetadata> metadata_handle_;
FeedbackMetadata metadata_;
FeedbackSlot cur_slot_;
FeedbackSlot next_slot_;
FeedbackSlotKind slot_kind_;
};
// A FeedbackNexus is the combination of a FeedbackVector and a slot.
class FeedbackNexus final {
public:
FeedbackNexus(Handle<FeedbackVector> vector, FeedbackSlot slot)
: vector_handle_(vector), slot_(slot) {
kind_ =
(vector.is_null()) ? FeedbackSlotKind::kInvalid : vector->GetKind(slot);
}
FeedbackNexus(FeedbackVector vector, FeedbackSlot slot)
: vector_(vector), slot_(slot) {
kind_ =
(vector.is_null()) ? FeedbackSlotKind::kInvalid : vector->GetKind(slot);
}
Handle<FeedbackVector> vector_handle() const {
DCHECK(vector_.is_null());
return vector_handle_;
}
FeedbackVector vector() const {
return vector_handle_.is_null() ? vector_ : *vector_handle_;
}
FeedbackSlot slot() const { return slot_; }
FeedbackSlotKind kind() const { return kind_; }
inline LanguageMode GetLanguageMode() const {
return vector()->GetLanguageMode(slot());
}
InlineCacheState ic_state() const { return StateFromFeedback(); }
bool IsUninitialized() const { return StateFromFeedback() == UNINITIALIZED; }
[turbofan] Optimize O.p.hasOwnProperty inside for-in. Optimize the common pattern for (var i in o) { if (Object.prototype.hasOwnProperty.call(o, i)) { // do something } } which is part of the guard-for-in style in ESLint (see the documentation at https://eslint.org/docs/rules/guard-for-in for details). This pattern also shows up in React and Ember applications quite a lot (and is tested by the appropriate Speedometer benchmarks, although not dominating those benchmarks, since they spent a lot of time in non-TurboFan'ed code). This improves the forInHasOwnProperty and forInHasOwnPropertySafe micro- benchmarks in v8:6702, which look like this function forInHasOwnProperty(o) { var result = 0; for (var i in o) { if (o.hasOwnProperty(i)) { result += 1; } } return result; } function forInHasOwnPropertySafe(o) { var result = 0; for (var i in o) { if (Object.prototype.hasOwnProperty.call(o, i)) { result += 1; } } return result; } by around 4x and allows for additional optimizations in the future, by also elimiating the megamorphic load when accessing the enumerated properties. This changes the interpreter ForInNext bytecode to collect more precise feedback about the for-in state, which now consists of three individual states: UNINITIALIZED, MEGAMORPHIC and GENERIC. The MEGAMORPHIC state means that the ForInNext has only seen objects with a usable enum cache thus far, whereas GENERIC means that we have seen some slow-mode for..in objects as well. R=jarin@chromium.org Bug: v8:6702 Change-Id: Ibcd75ea9b58c3b4f9219f11bc37eb04a2b985604 Reviewed-on: https://chromium-review.googlesource.com/636964 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47632}
2017-08-28 05:26:15 +00:00
bool IsMegamorphic() const { return StateFromFeedback() == MEGAMORPHIC; }
bool IsGeneric() const { return StateFromFeedback() == GENERIC; }
void Print(std::ostream& os); // NOLINT
// For map-based ICs (load, keyed-load, store, keyed-store).
Map FindFirstMap() const;
InlineCacheState StateFromFeedback() const;
int ExtractMaps(MapHandles* maps) const;
MaybeObjectHandle FindHandlerForMap(Handle<Map> map) const;
bool FindHandlers(MaybeObjectHandles* code_list, int length = -1) const;
bool IsCleared() const {
InlineCacheState state = StateFromFeedback();
return !FLAG_use_ic || state == UNINITIALIZED || state == PREMONOMORPHIC;
}
// Clear() returns true if the state of the underlying vector was changed.
bool Clear();
void ConfigureUninitialized();
[ic] Remember the receiver map in PREMONOMORPHIC state. When going to PREMONOMORPHIC state we previously stored the premonomorphic sentinel into the first IC slot and then the second slot was storing the uninitialized sentinel. So when TurboFan kicked in and optimized the function we'd just put a LOAD_IC in there and hoped for the best that this is either not in hot code or will reoptimize for another reason later to fixup the LOAD_IC. This is a quite annoying footgun for developers because the performance inevitably depends on timing of when the optimizing compiler kicks in. To fix this issue we now keep a weak reference to the receiver map in the second slot of the IC in PREMONOMORPHIC state and use that to speculatively optimize when we go to TurboFan. This improves the performance on the reported bug from spread: 2342 ms. spread: 2352 ms. spread: 2339 ms. to spread: 1490 ms. spread: 1451 ms. spread: 1445 ms. which corresponds to a 36% improvement in this particular case. In general you'll get more predictable performance with this change. We might want to also use the map when going to MONOMORPHIC state at a later point to maybe skip the additional transition to POLYMORPHIC in some cases, but that's independent of this bug. Bug: v8:5267, v8:7973 Change-Id: Ia4eef7651e219a40927531cdffe320ade1dd19a4 Reviewed-on: https://chromium-review.googlesource.com/1148205 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#54682}
2018-07-24 11:27:28 +00:00
void ConfigurePremonomorphic(Handle<Map> receiver_map);
[runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases As discussed in https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#, this CL introduces a new bytecode (CloneObject), and a new IC type. In this prototype implementation, the type feedback looks like the following: Uninitialized case: { uninitialized_sentinel, uninitialized_sentinel } Monomorphic case: { weak 'source' map, strong 'result' map } Polymorphic case: { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value } Megamorphic case: { megamorphic_sentinel, cleared_Value } In the fast case, Object cloning is done by allocating an object with the saved result map, and a shallow clone of the fast properties from the source object, as well as cloned fast elements from the source object. If at any point the fast case can't be taken, the IC transitions to the slow case and remains there. This prototype CL does not include any TurboFan optimization, and the CloneObject operation is merely reduced to a stub call. It may still be possible to get some further improvements by somehow incorporating compile-time boilerplate elements into the cloned object, or simplifying how the boilerplate elements are inserted into the object. In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/ by about 8x, with substantial improvements over the Babel and ObjectAssign scores. R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org BUG=v8:7611 Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e Reviewed-on: https://chromium-review.googlesource.com/1127472 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54595}
2018-07-20 15:24:04 +00:00
// ConfigureMegamorphic() returns true if the state of the underlying vector
// was changed. Extra feedback is cleared if the 0 parameter version is used.
bool ConfigureMegamorphic();
bool ConfigureMegamorphic(IcCheckType property_type);
inline MaybeObject GetFeedback() const;
inline MaybeObject GetFeedbackExtra() const;
inline Isolate* GetIsolate() const;
void ConfigureMonomorphic(Handle<Name> name, Handle<Map> receiver_map,
const MaybeObjectHandle& handler);
void ConfigurePolymorphic(Handle<Name> name, MapHandles const& maps,
MaybeObjectHandles* handlers);
BinaryOperationHint GetBinaryOperationFeedback() const;
CompareOperationHint GetCompareOperationFeedback() const;
ForInHint GetForInFeedback() const;
// For KeyedLoad ICs.
KeyedAccessLoadMode GetKeyedAccessLoadMode() const;
// For KeyedStore ICs.
KeyedAccessStoreMode GetKeyedAccessStoreMode() const;
// For KeyedLoad and KeyedStore ICs.
IcCheckType GetKeyType() const;
Name FindFirstName() const;
// For Call ICs.
int GetCallCount();
void SetSpeculationMode(SpeculationMode mode);
SpeculationMode GetSpeculationMode();
[turbofan] Collect invocation counts and compute relative call frequencies. Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:08 +00:00
// Compute the call frequency based on the call count and the invocation
// count (taken from the type feedback vector).
float ComputeCallFrequency();
typedef BitField<SpeculationMode, 0, 1> SpeculationModeField;
typedef BitField<uint32_t, 1, 31> CallCountField;
// For CreateClosure ICs.
Handle<FeedbackCell> GetFeedbackCell() const;
// For InstanceOf ICs.
MaybeHandle<JSObject> GetConstructorFeedback() const;
// For Global Load and Store ICs.
void ConfigurePropertyCellMode(Handle<PropertyCell> cell);
// Returns false if given combination of indices is not allowed.
Revert "Reland^3 "[turbofan] Use feedback when reducing global loads/stores."" This reverts commit 8683116e64335a99ecc403c509587410db070cd1. Reason for revert: There's a bug in the StoreGlobalIC that causes regressions in combination with this CL (observable in Chrome but not in d8). Original change's description: > Reland^3 "[turbofan] Use feedback when reducing global loads/stores." > > This is a reland of 2d2c1374929c7ff41bed6526103ba6217009057a without > changes. Offending chromium tests have been modified. > > Original change's description: > > Reland^2 "[turbofan] Use feedback when reducing global loads/stores." > > > > This reverts commit ac85ab0a3d520a0c13b7e9224bf012cc4d9aa717. A > > chromium test caused trouble and was taken care of in > > https://chromium-review.googlesource.com/c/1384064. > > > > Original change's description: > > > [turbofan] Use feedback when reducing global loads/stores. > > > > > > We already record the script context location or the property cell > > > as feedback of the global load/store IC, so Turbofan doesn't need > > > to do the lookups again. > > > > TBR=sigurds@chromium.org > > > > Change-Id: I58bcd9bceec2f9cf401f7b0fc4460a6da6cd0abc > > Reviewed-on: https://chromium-review.googlesource.com/c/1386404 > > Commit-Queue: Georg Neis <neis@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58393} > > Change-Id: Ic6734201a6c45f2752488ab44b16859776802f51 > Reviewed-on: https://chromium-review.googlesource.com/c/1408252 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58769} TBR=neis@chromium.org,sigurds@chromium.org,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:922545, chromium:922514, chromium:922558 Change-Id: I6e4c4c0fbc29a0f2a03972f1687242ae247ebfa8 Reviewed-on: https://chromium-review.googlesource.com/c/1417614 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#58891}
2019-01-17 14:31:01 +00:00
bool ConfigureLexicalVarMode(int script_context_index,
int context_slot_index);
void ConfigureHandlerMode(const MaybeObjectHandle& handler);
[runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases As discussed in https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#, this CL introduces a new bytecode (CloneObject), and a new IC type. In this prototype implementation, the type feedback looks like the following: Uninitialized case: { uninitialized_sentinel, uninitialized_sentinel } Monomorphic case: { weak 'source' map, strong 'result' map } Polymorphic case: { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value } Megamorphic case: { megamorphic_sentinel, cleared_Value } In the fast case, Object cloning is done by allocating an object with the saved result map, and a shallow clone of the fast properties from the source object, as well as cloned fast elements from the source object. If at any point the fast case can't be taken, the IC transitions to the slow case and remains there. This prototype CL does not include any TurboFan optimization, and the CloneObject operation is merely reduced to a stub call. It may still be possible to get some further improvements by somehow incorporating compile-time boilerplate elements into the cloned object, or simplifying how the boilerplate elements are inserted into the object. In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/ by about 8x, with substantial improvements over the Babel and ObjectAssign scores. R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org BUG=v8:7611 Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e Reviewed-on: https://chromium-review.googlesource.com/1127472 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54595}
2018-07-20 15:24:04 +00:00
// For CloneObject ICs
static constexpr int kCloneObjectPolymorphicEntrySize = 2;
void ConfigureCloneObject(Handle<Map> source_map, Handle<Map> result_map);
// Bit positions in a smi that encodes lexical environment variable access.
#define LEXICAL_MODE_BIT_FIELDS(V, _) \
V(ContextIndexBits, unsigned, 12, _) \
Revert "Reland^3 "[turbofan] Use feedback when reducing global loads/stores."" This reverts commit 8683116e64335a99ecc403c509587410db070cd1. Reason for revert: There's a bug in the StoreGlobalIC that causes regressions in combination with this CL (observable in Chrome but not in d8). Original change's description: > Reland^3 "[turbofan] Use feedback when reducing global loads/stores." > > This is a reland of 2d2c1374929c7ff41bed6526103ba6217009057a without > changes. Offending chromium tests have been modified. > > Original change's description: > > Reland^2 "[turbofan] Use feedback when reducing global loads/stores." > > > > This reverts commit ac85ab0a3d520a0c13b7e9224bf012cc4d9aa717. A > > chromium test caused trouble and was taken care of in > > https://chromium-review.googlesource.com/c/1384064. > > > > Original change's description: > > > [turbofan] Use feedback when reducing global loads/stores. > > > > > > We already record the script context location or the property cell > > > as feedback of the global load/store IC, so Turbofan doesn't need > > > to do the lookups again. > > > > TBR=sigurds@chromium.org > > > > Change-Id: I58bcd9bceec2f9cf401f7b0fc4460a6da6cd0abc > > Reviewed-on: https://chromium-review.googlesource.com/c/1386404 > > Commit-Queue: Georg Neis <neis@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58393} > > Change-Id: Ic6734201a6c45f2752488ab44b16859776802f51 > Reviewed-on: https://chromium-review.googlesource.com/c/1408252 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58769} TBR=neis@chromium.org,sigurds@chromium.org,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:922545, chromium:922514, chromium:922558 Change-Id: I6e4c4c0fbc29a0f2a03972f1687242ae247ebfa8 Reviewed-on: https://chromium-review.googlesource.com/c/1417614 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#58891}
2019-01-17 14:31:01 +00:00
V(SlotIndexBits, unsigned, 19, _)
DEFINE_BIT_FIELDS(LEXICAL_MODE_BIT_FIELDS)
#undef LEXICAL_MODE_BIT_FIELDS
// Make sure we don't overflow the smi.
STATIC_ASSERT(LEXICAL_MODE_BIT_FIELDS_Ranges::kBitsCount <= kSmiValueSize);
// For TypeProfile feedback vector slots.
// ResetTypeProfile will always reset type profile information.
void ResetTypeProfile();
Collect type profile for DevTools Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. For now, has a test that compares the stdout of --type-profile in test/message. We will remove this test when --type-profile is fully integrated in the debugger protocol. Adding the test in test/inspector does not work, because the inspector test itself consists of JavaScript code that would convolute the output and be non-deterministic under stress. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43866}
2017-03-16 15:01:31 +00:00
// Add a type to the list of types for source position <position>.
void Collect(Handle<String> type, int position);
JSObject GetTypeProfile() const;
Collect type profile for DevTools Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. For now, has a test that compares the stdout of --type-profile in test/message. We will remove this test when --type-profile is fully integrated in the debugger protocol. Adding the test in test/inspector does not work, because the inspector test itself consists of JavaScript code that would convolute the output and be non-deterministic under stress. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43866}
2017-03-16 15:01:31 +00:00
[type-profile] Incorporate into inspector protocol. JavaScript is a dynamically typed language. But most code is written with fixed types in mind. When debugging JavaScript, it is helpful to know the types of variables and parameters at runtime. It is often hard to infer types for complex code. Type profiling provides this information at runtime. Node.js uses the inspector protocol. This CL allows Node.js users to access and analyse type profile for via Node modules or the in-procress api. Type Profile helps developers to analyze their code for correctness and performance. Design doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing Add `takeTypeProfile` to the inspector protocol. It returns a list of TypeProfileForScripts, which in turn contains the type profile for each function. We can use TypeProfile data to annotate JavaScript code. Sample script with data from TypeProfile: function f(/*Object, number, undefined*/a, /*Array, number, null*/b, /*boolean, Object, symbol*/c) { return 'bye'; /*string*/}; f({}, [], true); f(3, 2.3, {a: 42}); f(undefined, null, Symbol('hello'));/*string*/ Bug: v8:5933 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I626bfb886b752f90b9c86cc6953601558b18b60d Reviewed-on: https://chromium-review.googlesource.com/508588 Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47920}
2017-09-08 08:28:29 +00:00
std::vector<int> GetSourcePositions() const;
std::vector<Handle<String>> GetTypesForSourcePositions(uint32_t pos) const;
inline void SetFeedback(Object feedback,
WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
inline void SetFeedback(MaybeObject feedback,
WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
inline void SetFeedbackExtra(Object feedback_extra,
WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
inline void SetFeedbackExtra(MaybeObject feedback_extra,
WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
Handle<WeakFixedArray> EnsureArrayOfSize(int length);
Handle<WeakFixedArray> EnsureExtraArrayOfSize(int length);
[type-profile] Incorporate into inspector protocol. JavaScript is a dynamically typed language. But most code is written with fixed types in mind. When debugging JavaScript, it is helpful to know the types of variables and parameters at runtime. It is often hard to infer types for complex code. Type profiling provides this information at runtime. Node.js uses the inspector protocol. This CL allows Node.js users to access and analyse type profile for via Node modules or the in-procress api. Type Profile helps developers to analyze their code for correctness and performance. Design doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing Add `takeTypeProfile` to the inspector protocol. It returns a list of TypeProfileForScripts, which in turn contains the type profile for each function. We can use TypeProfile data to annotate JavaScript code. Sample script with data from TypeProfile: function f(/*Object, number, undefined*/a, /*Array, number, null*/b, /*boolean, Object, symbol*/c) { return 'bye'; /*string*/}; f({}, [], true); f(3, 2.3, {a: 42}); f(undefined, null, Symbol('hello'));/*string*/ Bug: v8:5933 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I626bfb886b752f90b9c86cc6953601558b18b60d Reviewed-on: https://chromium-review.googlesource.com/508588 Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47920}
2017-09-08 08:28:29 +00:00
private:
// The reason for having a vector handle and a raw pointer is that we can and
// should use handles during IC miss, but not during GC when we clear ICs. If
// you have a handle to the vector that is better because more operations can
// be done, like allocation.
Handle<FeedbackVector> vector_handle_;
FeedbackVector vector_;
FeedbackSlot slot_;
FeedbackSlotKind kind_;
Collect type profile for DevTools Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. For now, has a test that compares the stdout of --type-profile in test/message. We will remove this test when --type-profile is fully integrated in the debugger protocol. Adding the test in test/inspector does not work, because the inspector test itself consists of JavaScript code that would convolute the output and be non-deterministic under stress. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43866}
2017-03-16 15:01:31 +00:00
};
inline BinaryOperationHint BinaryOperationHintFromFeedback(int type_feedback);
inline CompareOperationHint CompareOperationHintFromFeedback(int type_feedback);
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
inline ForInHint ForInHintFromFeedback(int type_feedback);
} // namespace internal
} // namespace v8
#include "src/objects/object-macros-undef.h"
#endif // V8_FEEDBACK_VECTOR_H_