v8/src/object-observe.js

703 lines
20 KiB
JavaScript
Raw Normal View History

// Copyright 2012 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.
var $observeNotifyChange;
var $observeEnqueueSpliceRecord;
var $observeBeginPerformSplice;
var $observeEndPerformSplice;
var $observeNativeObjectObserve;
var $observeNativeObjectGetNotifier;
var $observeNativeObjectNotifierPerformChange;
(function(global, utils) {
"use strict";
%CheckIsBootstrapping();
// -------------------------------------------------------------------
// Imports
var GlobalArray = global.Array;
var GlobalObject = global.Object;
var InternalArray = utils.InternalArray;
var ObjectFreeze;
var ObjectIsFrozen;
utils.Import(function(from) {
ObjectFreeze = from.ObjectFreeze;
ObjectIsFrozen = from.ObjectIsFrozen;
});
// -------------------------------------------------------------------
// Overview:
//
// This file contains all of the routing and accounting for Object.observe.
// User code will interact with these mechanisms via the Object.observe APIs
// and, as a side effect of mutation objects which are observed. The V8 runtime
// (both C++ and JS) will interact with these mechanisms primarily by enqueuing
// proper change records for objects which were mutated. The Object.observe
// routing and accounting consists primarily of three participants
//
// 1) ObjectInfo. This represents the observed state of a given object. It
// records what callbacks are observing the object, with what options, and
// what "change types" are in progress on the object (i.e. via
// notifier.performChange).
//
// 2) CallbackInfo. This represents a callback used for observation. It holds
// the records which must be delivered to the callback, as well as the global
// priority of the callback (which determines delivery order between
// callbacks).
//
// 3) observationState.pendingObservers. This is the set of observers which
// have change records which must be delivered. During "normal" delivery
// (i.e. not Object.deliverChangeRecords), this is the mechanism by which
// callbacks are invoked in the proper order until there are no more
// change records pending to a callback.
//
// Note that in order to reduce allocation and processing costs, the
// implementation of (1) and (2) have "optimized" states which represent
// common cases which can be handled more efficiently.
var observationState;
var notifierPrototype = {};
// We have to wait until after bootstrapping to grab a reference to the
// observationState object, since it's not possible to serialize that
// reference into the snapshot.
function GetObservationStateJS() {
if (IS_UNDEFINED(observationState)) {
observationState = %GetObservationState();
}
// TODO(adamk): Consider moving this code into heap.cc
if (IS_UNDEFINED(observationState.callbackInfoMap)) {
observationState.callbackInfoMap = %ObservationWeakMapCreate();
observationState.objectInfoMap = %ObservationWeakMapCreate();
observationState.notifierObjectInfoMap = %ObservationWeakMapCreate();
observationState.pendingObservers = null;
observationState.nextCallbackPriority = 0;
observationState.lastMicrotaskId = 0;
}
return observationState;
}
function GetPendingObservers() {
return GetObservationStateJS().pendingObservers;
}
function SetPendingObservers(pendingObservers) {
GetObservationStateJS().pendingObservers = pendingObservers;
}
function GetNextCallbackPriority() {
return GetObservationStateJS().nextCallbackPriority++;
}
function nullProtoObject() {
return { __proto__: null };
}
function TypeMapCreate() {
return nullProtoObject();
}
function TypeMapAddType(typeMap, type, ignoreDuplicate) {
typeMap[type] = ignoreDuplicate ? 1 : (typeMap[type] || 0) + 1;
}
function TypeMapRemoveType(typeMap, type) {
typeMap[type]--;
}
function TypeMapCreateFromList(typeList, length) {
var typeMap = TypeMapCreate();
for (var i = 0; i < length; i++) {
TypeMapAddType(typeMap, typeList[i], true);
}
return typeMap;
}
function TypeMapHasType(typeMap, type) {
return !!typeMap[type];
}
function TypeMapIsDisjointFrom(typeMap1, typeMap2) {
if (!typeMap1 || !typeMap2)
return true;
for (var type in typeMap1) {
if (TypeMapHasType(typeMap1, type) && TypeMapHasType(typeMap2, type))
return false;
}
return true;
}
var defaultAcceptTypes = (function() {
var defaultTypes = [
'add',
'update',
'delete',
'setPrototype',
'reconfigure',
'preventExtensions'
];
return TypeMapCreateFromList(defaultTypes, defaultTypes.length);
})();
// An Observer is a registration to observe an object by a callback with
// a given set of accept types. If the set of accept types is the default
// set for Object.observe, the observer is represented as a direct reference
// to the callback. An observer never changes its accept types and thus never
// needs to "normalize".
function ObserverCreate(callback, acceptList) {
if (IS_UNDEFINED(acceptList))
return callback;
var observer = nullProtoObject();
observer.callback = callback;
observer.accept = acceptList;
return observer;
}
function ObserverGetCallback(observer) {
return IS_SPEC_FUNCTION(observer) ? observer : observer.callback;
}
function ObserverGetAcceptTypes(observer) {
return IS_SPEC_FUNCTION(observer) ? defaultAcceptTypes : observer.accept;
}
function ObserverIsActive(observer, objectInfo) {
return TypeMapIsDisjointFrom(ObjectInfoGetPerformingTypes(objectInfo),
ObserverGetAcceptTypes(observer));
}
function ObjectInfoGetOrCreate(object) {
var objectInfo = ObjectInfoGet(object);
if (IS_UNDEFINED(objectInfo)) {
if (!%_IsJSProxy(object)) {
%SetIsObserved(object);
}
objectInfo = {
object: object,
changeObservers: null,
notifier: null,
performing: null,
performingCount: 0,
};
%WeakCollectionSet(GetObservationStateJS().objectInfoMap,
Move hash code from hidden string to a private symbol * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols. * In the long run we should do all hidden properties this way and get rid of the hidden magic 0-length string with the zero hash code. The advantages include less complexity and being able to do things from JS in a natural way. * Initially, the performance of weak set regressed, because it's a little harder to do the lookup in C++. Instead of heroics in C++ to make things faster I moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects. * This also changes hash codes of Smis so that they are always Smis. Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(. In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win. In a similar vein we could give the magic zero hash code to the hash code symbol. Then when we look up the hash code we would sometimes see the table with all the hidden properties. This dual use of the field for either the hash code or the table with all hidden properties and the hash code is rather ugly, and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL. One worry is that the benchmark results above are more monomorphic than real world code, so may be overstating the performance benefits of moving to JS. I think this is part of a general issue we have with handling polymorphic code in JS and any solutions there will benefit this solution, which boils down to regular property access. Any improvement there will lift all boats. R=adamk@chromium.org, verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1149863005 Cr-Commit-Position: refs/heads/master@{#28622}
2015-05-26 11:26:26 +00:00
object, objectInfo, $getHash(object));
}
return objectInfo;
}
function ObjectInfoGet(object) {
Move hash code from hidden string to a private symbol * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols. * In the long run we should do all hidden properties this way and get rid of the hidden magic 0-length string with the zero hash code. The advantages include less complexity and being able to do things from JS in a natural way. * Initially, the performance of weak set regressed, because it's a little harder to do the lookup in C++. Instead of heroics in C++ to make things faster I moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects. * This also changes hash codes of Smis so that they are always Smis. Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(. In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win. In a similar vein we could give the magic zero hash code to the hash code symbol. Then when we look up the hash code we would sometimes see the table with all the hidden properties. This dual use of the field for either the hash code or the table with all hidden properties and the hash code is rather ugly, and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL. One worry is that the benchmark results above are more monomorphic than real world code, so may be overstating the performance benefits of moving to JS. I think this is part of a general issue we have with handling polymorphic code in JS and any solutions there will benefit this solution, which boils down to regular property access. Any improvement there will lift all boats. R=adamk@chromium.org, verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1149863005 Cr-Commit-Position: refs/heads/master@{#28622}
2015-05-26 11:26:26 +00:00
return %WeakCollectionGet(GetObservationStateJS().objectInfoMap, object,
$getHash(object));
}
function ObjectInfoGetFromNotifier(notifier) {
return %WeakCollectionGet(GetObservationStateJS().notifierObjectInfoMap,
Move hash code from hidden string to a private symbol * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols. * In the long run we should do all hidden properties this way and get rid of the hidden magic 0-length string with the zero hash code. The advantages include less complexity and being able to do things from JS in a natural way. * Initially, the performance of weak set regressed, because it's a little harder to do the lookup in C++. Instead of heroics in C++ to make things faster I moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects. * This also changes hash codes of Smis so that they are always Smis. Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(. In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win. In a similar vein we could give the magic zero hash code to the hash code symbol. Then when we look up the hash code we would sometimes see the table with all the hidden properties. This dual use of the field for either the hash code or the table with all hidden properties and the hash code is rather ugly, and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL. One worry is that the benchmark results above are more monomorphic than real world code, so may be overstating the performance benefits of moving to JS. I think this is part of a general issue we have with handling polymorphic code in JS and any solutions there will benefit this solution, which boils down to regular property access. Any improvement there will lift all boats. R=adamk@chromium.org, verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1149863005 Cr-Commit-Position: refs/heads/master@{#28622}
2015-05-26 11:26:26 +00:00
notifier, $getHash(notifier));
}
function ObjectInfoGetNotifier(objectInfo) {
if (IS_NULL(objectInfo.notifier)) {
Move hash code from hidden string to a private symbol * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols. * In the long run we should do all hidden properties this way and get rid of the hidden magic 0-length string with the zero hash code. The advantages include less complexity and being able to do things from JS in a natural way. * Initially, the performance of weak set regressed, because it's a little harder to do the lookup in C++. Instead of heroics in C++ to make things faster I moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects. * This also changes hash codes of Smis so that they are always Smis. Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(. In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win. In a similar vein we could give the magic zero hash code to the hash code symbol. Then when we look up the hash code we would sometimes see the table with all the hidden properties. This dual use of the field for either the hash code or the table with all hidden properties and the hash code is rather ugly, and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL. One worry is that the benchmark results above are more monomorphic than real world code, so may be overstating the performance benefits of moving to JS. I think this is part of a general issue we have with handling polymorphic code in JS and any solutions there will benefit this solution, which boils down to regular property access. Any improvement there will lift all boats. R=adamk@chromium.org, verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1149863005 Cr-Commit-Position: refs/heads/master@{#28622}
2015-05-26 11:26:26 +00:00
var notifier = { __proto__: notifierPrototype };
objectInfo.notifier = notifier;
%WeakCollectionSet(GetObservationStateJS().notifierObjectInfoMap,
Move hash code from hidden string to a private symbol * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols. * In the long run we should do all hidden properties this way and get rid of the hidden magic 0-length string with the zero hash code. The advantages include less complexity and being able to do things from JS in a natural way. * Initially, the performance of weak set regressed, because it's a little harder to do the lookup in C++. Instead of heroics in C++ to make things faster I moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects. * This also changes hash codes of Smis so that they are always Smis. Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(. In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win. In a similar vein we could give the magic zero hash code to the hash code symbol. Then when we look up the hash code we would sometimes see the table with all the hidden properties. This dual use of the field for either the hash code or the table with all hidden properties and the hash code is rather ugly, and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL. One worry is that the benchmark results above are more monomorphic than real world code, so may be overstating the performance benefits of moving to JS. I think this is part of a general issue we have with handling polymorphic code in JS and any solutions there will benefit this solution, which boils down to regular property access. Any improvement there will lift all boats. R=adamk@chromium.org, verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1149863005 Cr-Commit-Position: refs/heads/master@{#28622}
2015-05-26 11:26:26 +00:00
notifier, objectInfo, $getHash(notifier));
}
return objectInfo.notifier;
}
function ChangeObserversIsOptimized(changeObservers) {
return IS_SPEC_FUNCTION(changeObservers) ||
IS_SPEC_FUNCTION(changeObservers.callback);
}
// The set of observers on an object is called 'changeObservers'. The first
// observer is referenced directly via objectInfo.changeObservers. When a second
// is added, changeObservers "normalizes" to become a mapping of callback
// priority -> observer and is then stored on objectInfo.changeObservers.
function ObjectInfoNormalizeChangeObservers(objectInfo) {
if (ChangeObserversIsOptimized(objectInfo.changeObservers)) {
var observer = objectInfo.changeObservers;
var callback = ObserverGetCallback(observer);
var callbackInfo = CallbackInfoGet(callback);
var priority = CallbackInfoGetPriority(callbackInfo);
objectInfo.changeObservers = nullProtoObject();
objectInfo.changeObservers[priority] = observer;
}
}
function ObjectInfoAddObserver(objectInfo, callback, acceptList) {
var callbackInfo = CallbackInfoGetOrCreate(callback);
var observer = ObserverCreate(callback, acceptList);
if (!objectInfo.changeObservers) {
objectInfo.changeObservers = observer;
return;
}
ObjectInfoNormalizeChangeObservers(objectInfo);
var priority = CallbackInfoGetPriority(callbackInfo);
objectInfo.changeObservers[priority] = observer;
}
function ObjectInfoRemoveObserver(objectInfo, callback) {
if (!objectInfo.changeObservers)
return;
if (ChangeObserversIsOptimized(objectInfo.changeObservers)) {
if (callback === ObserverGetCallback(objectInfo.changeObservers))
objectInfo.changeObservers = null;
return;
}
var callbackInfo = CallbackInfoGet(callback);
var priority = CallbackInfoGetPriority(callbackInfo);
objectInfo.changeObservers[priority] = null;
}
function ObjectInfoHasActiveObservers(objectInfo) {
if (IS_UNDEFINED(objectInfo) || !objectInfo.changeObservers)
return false;
if (ChangeObserversIsOptimized(objectInfo.changeObservers))
return ObserverIsActive(objectInfo.changeObservers, objectInfo);
for (var priority in objectInfo.changeObservers) {
var observer = objectInfo.changeObservers[priority];
if (!IS_NULL(observer) && ObserverIsActive(observer, objectInfo))
return true;
}
return false;
}
function ObjectInfoAddPerformingType(objectInfo, type) {
objectInfo.performing = objectInfo.performing || TypeMapCreate();
TypeMapAddType(objectInfo.performing, type);
objectInfo.performingCount++;
}
function ObjectInfoRemovePerformingType(objectInfo, type) {
objectInfo.performingCount--;
TypeMapRemoveType(objectInfo.performing, type);
}
function ObjectInfoGetPerformingTypes(objectInfo) {
return objectInfo.performingCount > 0 ? objectInfo.performing : null;
}
function ConvertAcceptListToTypeMap(arg) {
// We use undefined as a sentinel for the default accept list.
if (IS_UNDEFINED(arg))
return arg;
if (!IS_SPEC_OBJECT(arg)) throw MakeTypeError(kObserveInvalidAccept);
var len = $toInteger(arg.length);
if (len < 0) len = 0;
return TypeMapCreateFromList(arg, len);
}
// CallbackInfo's optimized state is just a number which represents its global
// priority. When a change record must be enqueued for the callback, it
// normalizes. When delivery clears any pending change records, it re-optimizes.
function CallbackInfoGet(callback) {
Move hash code from hidden string to a private symbol * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols. * In the long run we should do all hidden properties this way and get rid of the hidden magic 0-length string with the zero hash code. The advantages include less complexity and being able to do things from JS in a natural way. * Initially, the performance of weak set regressed, because it's a little harder to do the lookup in C++. Instead of heroics in C++ to make things faster I moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects. * This also changes hash codes of Smis so that they are always Smis. Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(. In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win. In a similar vein we could give the magic zero hash code to the hash code symbol. Then when we look up the hash code we would sometimes see the table with all the hidden properties. This dual use of the field for either the hash code or the table with all hidden properties and the hash code is rather ugly, and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL. One worry is that the benchmark results above are more monomorphic than real world code, so may be overstating the performance benefits of moving to JS. I think this is part of a general issue we have with handling polymorphic code in JS and any solutions there will benefit this solution, which boils down to regular property access. Any improvement there will lift all boats. R=adamk@chromium.org, verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1149863005 Cr-Commit-Position: refs/heads/master@{#28622}
2015-05-26 11:26:26 +00:00
return %WeakCollectionGet(GetObservationStateJS().callbackInfoMap, callback,
$getHash(callback));
}
function CallbackInfoSet(callback, callbackInfo) {
%WeakCollectionSet(GetObservationStateJS().callbackInfoMap,
Move hash code from hidden string to a private symbol * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols. * In the long run we should do all hidden properties this way and get rid of the hidden magic 0-length string with the zero hash code. The advantages include less complexity and being able to do things from JS in a natural way. * Initially, the performance of weak set regressed, because it's a little harder to do the lookup in C++. Instead of heroics in C++ to make things faster I moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects. * This also changes hash codes of Smis so that they are always Smis. Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(. In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win. In a similar vein we could give the magic zero hash code to the hash code symbol. Then when we look up the hash code we would sometimes see the table with all the hidden properties. This dual use of the field for either the hash code or the table with all hidden properties and the hash code is rather ugly, and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL. One worry is that the benchmark results above are more monomorphic than real world code, so may be overstating the performance benefits of moving to JS. I think this is part of a general issue we have with handling polymorphic code in JS and any solutions there will benefit this solution, which boils down to regular property access. Any improvement there will lift all boats. R=adamk@chromium.org, verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1149863005 Cr-Commit-Position: refs/heads/master@{#28622}
2015-05-26 11:26:26 +00:00
callback, callbackInfo, $getHash(callback));
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
}
function CallbackInfoGetOrCreate(callback) {
var callbackInfo = CallbackInfoGet(callback);
if (!IS_UNDEFINED(callbackInfo))
return callbackInfo;
var priority = GetNextCallbackPriority();
CallbackInfoSet(callback, priority);
return priority;
}
function CallbackInfoGetPriority(callbackInfo) {
if (IS_NUMBER(callbackInfo))
return callbackInfo;
else
return callbackInfo.priority;
}
function CallbackInfoNormalize(callback) {
var callbackInfo = CallbackInfoGet(callback);
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
if (IS_NUMBER(callbackInfo)) {
var priority = callbackInfo;
callbackInfo = new InternalArray;
callbackInfo.priority = priority;
CallbackInfoSet(callback, callbackInfo);
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
}
return callbackInfo;
}
function ObjectObserve(object, callback, acceptList) {
if (!IS_SPEC_OBJECT(object))
throw MakeTypeError(kObserveNonObject, "observe", "observe");
if (%IsJSGlobalProxy(object))
throw MakeTypeError(kObserveGlobalProxy, "observe");
if (!IS_SPEC_FUNCTION(callback))
throw MakeTypeError(kObserveNonFunction, "observe");
if (ObjectIsFrozen(callback))
throw MakeTypeError(kObserveCallbackFrozen);
var objectObserveFn = %GetObjectContextObjectObserve(object);
return objectObserveFn(object, callback, acceptList);
}
function NativeObjectObserve(object, callback, acceptList) {
var objectInfo = ObjectInfoGetOrCreate(object);
var typeList = ConvertAcceptListToTypeMap(acceptList);
ObjectInfoAddObserver(objectInfo, callback, typeList);
return object;
}
function ObjectUnobserve(object, callback) {
if (!IS_SPEC_OBJECT(object))
throw MakeTypeError(kObserveNonObject, "unobserve", "unobserve");
if (%IsJSGlobalProxy(object))
throw MakeTypeError(kObserveGlobalProxy, "unobserve");
if (!IS_SPEC_FUNCTION(callback))
throw MakeTypeError(kObserveNonFunction, "unobserve");
var objectInfo = ObjectInfoGet(object);
if (IS_UNDEFINED(objectInfo))
return object;
ObjectInfoRemoveObserver(objectInfo, callback);
return object;
}
function ArrayObserve(object, callback) {
return ObjectObserve(object, callback, ['add',
'update',
'delete',
'splice']);
}
function ArrayUnobserve(object, callback) {
return ObjectUnobserve(object, callback);
}
function ObserverEnqueueIfActive(observer, objectInfo, changeRecord) {
if (!ObserverIsActive(observer, objectInfo) ||
!TypeMapHasType(ObserverGetAcceptTypes(observer), changeRecord.type)) {
return;
}
var callback = ObserverGetCallback(observer);
if (!%ObserverObjectAndRecordHaveSameOrigin(callback, changeRecord.object,
changeRecord)) {
return;
}
var callbackInfo = CallbackInfoNormalize(callback);
if (IS_NULL(GetPendingObservers())) {
SetPendingObservers(nullProtoObject());
if (DEBUG_IS_ACTIVE) {
var id = ++GetObservationStateJS().lastMicrotaskId;
var name = "Object.observe";
%EnqueueMicrotask(function() {
%DebugAsyncTaskEvent({ type: "willHandle", id: id, name: name });
ObserveMicrotaskRunner();
%DebugAsyncTaskEvent({ type: "didHandle", id: id, name: name });
});
%DebugAsyncTaskEvent({ type: "enqueue", id: id, name: name });
} else {
%EnqueueMicrotask(ObserveMicrotaskRunner);
}
}
GetPendingObservers()[callbackInfo.priority] = callback;
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
callbackInfo.push(changeRecord);
}
function ObjectInfoEnqueueExternalChangeRecord(objectInfo, changeRecord, type) {
if (!ObjectInfoHasActiveObservers(objectInfo))
return;
var hasType = !IS_UNDEFINED(type);
var newRecord = hasType ?
{ object: objectInfo.object, type: type } :
{ object: objectInfo.object };
for (var prop in changeRecord) {
if (prop === 'object' || (hasType && prop === 'type')) continue;
%DefineDataPropertyUnchecked(
newRecord, prop, changeRecord[prop], READ_ONLY + DONT_DELETE);
}
ObjectFreeze(newRecord);
ObjectInfoEnqueueInternalChangeRecord(objectInfo, newRecord);
}
function ObjectInfoEnqueueInternalChangeRecord(objectInfo, changeRecord) {
// TODO(rossberg): adjust once there is a story for symbols vs proxies.
if (IS_SYMBOL(changeRecord.name)) return;
if (ChangeObserversIsOptimized(objectInfo.changeObservers)) {
var observer = objectInfo.changeObservers;
ObserverEnqueueIfActive(observer, objectInfo, changeRecord);
return;
}
for (var priority in objectInfo.changeObservers) {
var observer = objectInfo.changeObservers[priority];
if (IS_NULL(observer))
continue;
ObserverEnqueueIfActive(observer, objectInfo, changeRecord);
}
}
function BeginPerformSplice(array) {
var objectInfo = ObjectInfoGet(array);
if (!IS_UNDEFINED(objectInfo))
ObjectInfoAddPerformingType(objectInfo, 'splice');
}
function EndPerformSplice(array) {
var objectInfo = ObjectInfoGet(array);
if (!IS_UNDEFINED(objectInfo))
ObjectInfoRemovePerformingType(objectInfo, 'splice');
}
function EnqueueSpliceRecord(array, index, removed, addedCount) {
var objectInfo = ObjectInfoGet(array);
if (!ObjectInfoHasActiveObservers(objectInfo))
return;
var changeRecord = {
type: 'splice',
object: array,
index: index,
removed: removed,
addedCount: addedCount
};
ObjectFreeze(changeRecord);
ObjectFreeze(changeRecord.removed);
ObjectInfoEnqueueInternalChangeRecord(objectInfo, changeRecord);
}
function NotifyChange(type, object, name, oldValue) {
var objectInfo = ObjectInfoGet(object);
if (!ObjectInfoHasActiveObservers(objectInfo))
return;
var changeRecord;
if (arguments.length == 2) {
changeRecord = { type: type, object: object };
} else if (arguments.length == 3) {
changeRecord = { type: type, object: object, name: name };
} else {
changeRecord = {
type: type,
object: object,
name: name,
oldValue: oldValue
};
}
ObjectFreeze(changeRecord);
ObjectInfoEnqueueInternalChangeRecord(objectInfo, changeRecord);
}
function ObjectNotifierNotify(changeRecord) {
if (!IS_SPEC_OBJECT(this))
throw MakeTypeError(kCalledOnNonObject, "notify");
var objectInfo = ObjectInfoGetFromNotifier(this);
if (IS_UNDEFINED(objectInfo))
throw MakeTypeError(kObserveNotifyNonNotifier);
if (!IS_STRING(changeRecord.type))
throw MakeTypeError(kObserveTypeNonString);
ObjectInfoEnqueueExternalChangeRecord(objectInfo, changeRecord);
}
function ObjectNotifierPerformChange(changeType, changeFn) {
if (!IS_SPEC_OBJECT(this))
throw MakeTypeError(kCalledOnNonObject, "performChange");
var objectInfo = ObjectInfoGetFromNotifier(this);
if (IS_UNDEFINED(objectInfo))
throw MakeTypeError(kObserveNotifyNonNotifier);
if (!IS_STRING(changeType))
throw MakeTypeError(kObservePerformNonString);
if (!IS_SPEC_FUNCTION(changeFn))
throw MakeTypeError(kObservePerformNonFunction);
var performChangeFn = %GetObjectContextNotifierPerformChange(objectInfo);
performChangeFn(objectInfo, changeType, changeFn);
}
function NativeObjectNotifierPerformChange(objectInfo, changeType, changeFn) {
ObjectInfoAddPerformingType(objectInfo, changeType);
var changeRecord;
try {
changeRecord = %_CallFunction(UNDEFINED, changeFn);
} finally {
ObjectInfoRemovePerformingType(objectInfo, changeType);
}
if (IS_SPEC_OBJECT(changeRecord))
ObjectInfoEnqueueExternalChangeRecord(objectInfo, changeRecord, changeType);
}
function ObjectGetNotifier(object) {
if (!IS_SPEC_OBJECT(object))
throw MakeTypeError(kObserveNonObject, "getNotifier", "getNotifier");
if (%IsJSGlobalProxy(object))
throw MakeTypeError(kObserveGlobalProxy, "getNotifier");
if (ObjectIsFrozen(object)) return null;
if (!%ObjectWasCreatedInCurrentOrigin(object)) return null;
var getNotifierFn = %GetObjectContextObjectGetNotifier(object);
return getNotifierFn(object);
}
function NativeObjectGetNotifier(object) {
var objectInfo = ObjectInfoGetOrCreate(object);
return ObjectInfoGetNotifier(objectInfo);
}
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
function CallbackDeliverPending(callback) {
var callbackInfo = CallbackInfoGet(callback);
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
if (IS_UNDEFINED(callbackInfo) || IS_NUMBER(callbackInfo))
return false;
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
// Clear the pending change records from callback and return it to its
// "optimized" state.
var priority = callbackInfo.priority;
CallbackInfoSet(callback, priority);
var pendingObservers = GetPendingObservers();
if (!IS_NULL(pendingObservers))
delete pendingObservers[priority];
// TODO: combine the following runtime calls for perf optimization.
var delivered = [];
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
%MoveArrayContents(callbackInfo, delivered);
%DeliverObservationChangeRecords(callback, delivered);
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
return true;
}
function ObjectDeliverChangeRecords(callback) {
if (!IS_SPEC_FUNCTION(callback))
throw MakeTypeError(kObserveNonFunction, "deliverChangeRecords");
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
while (CallbackDeliverPending(callback)) {}
}
function ObserveMicrotaskRunner() {
var pendingObservers = GetPendingObservers();
if (!IS_NULL(pendingObservers)) {
SetPendingObservers(null);
for (var i in pendingObservers) {
[Object.observe] Lazily allocate callbackInfo structure This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred. When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state. --- Note: Naming confusion resolved: This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map). This patch resolves this confusion: "object" (objectInfo, objectInfoMap): This refers to the observed object and its structures "callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered "observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list. --- R=rossberg@chromium.org Review URL: https://codereview.chromium.org/19132002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-15 22:16:30 +00:00
CallbackDeliverPending(pendingObservers[i]);
}
}
}
// -------------------------------------------------------------------
utils.InstallFunctions(GlobalObject, DONT_ENUM, [
"deliverChangeRecords", ObjectDeliverChangeRecords,
"getNotifier", ObjectGetNotifier,
"observe", ObjectObserve,
"unobserve", ObjectUnobserve
]);
utils.InstallFunctions(GlobalArray, DONT_ENUM, [
"observe", ArrayObserve,
"unobserve", ArrayUnobserve
]);
utils.InstallFunctions(notifierPrototype, DONT_ENUM, [
"notify", ObjectNotifierNotify,
"performChange", ObjectNotifierPerformChange
]);
$observeNotifyChange = NotifyChange;
$observeEnqueueSpliceRecord = EnqueueSpliceRecord;
$observeBeginPerformSplice = BeginPerformSplice;
$observeEndPerformSplice = EndPerformSplice;
$observeNativeObjectObserve = NativeObjectObserve;
$observeNativeObjectGetNotifier = NativeObjectGetNotifier;
$observeNativeObjectNotifierPerformChange = NativeObjectNotifierPerformChange;
})