Such properties never notified prior to r21558, but the combination of
that change and r23163 led to sending notifications when they were
set via Object.defineProperty (but not when set via other means).
This also allows some cleanup in v8natives.js and objects.cc,
both of which were doing unnecessary contortions to produce the right
change records.
BUG=v8:3745
LOG=n
Review URL: https://codereview.chromium.org/791243002
Cr-Commit-Position: refs/heads/master@{#25806}
Now we remember new space's top pointer after the last GC to find out if there was a new space allocation since the last GC.
Unfortunately, this not completely safe - the debugger has a callback hook (that can call to JS) at the end of the GC epilogue that can in theory allocate and possibly make the heap non-iterable. We can only hope this does not happen.
BUG=373283
R=hpayer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/291193005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Due to overlapping names of natives and runtime functions, the wrong
context was used for Notifier.prototype.performChange. The leak test
has been augmented to properly cover the leaky case, and the test
now passes.
Also tightened up type checks in runtime.cc and removed Object.observe
functions from knownIssues in fuzz-natives-part2.js.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/264793015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21129 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch reverts r21062 which disabled Object.observe and the relevant tests.
It also adds enforcement for the following three invariants:
1) No observer may receive a change record describing changes to an object which is in different security origin (context have differing security tokens)
2) No observer may receive a change record whose context's security token is different from that of the object described by the change.
3) Object.getNotifier will return null if the caller and the provided object are in differing security origins
Further, it ensures that the global object can never be observed nor a notifier retrieved for it.
Tests are included.
R=verwaest@chromium.org, rossberg
LOG=Y
Review URL: https://codereview.chromium.org/265503002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change is mostly straightforward: for 'normal' sorts of change records,
simply don't deliver a changeRecord to a given observer callback if an access
the callback's Context is not allowed to "GET" or "HAS" changeRecord.name on
changeRecord.object, or if ACCESS_KEYS is disallowed.
For 'splice' records, the question of whether to hand it to an observer is trickier, since
there are multiple properties involved, and multiple types of possible information leakage.
Given that access-checked objects are very rare (only two in Blink, Window and Location),
and that they are not normally used as Arrays, it seems better to simply not emit any splice
records for such objects rather than spending lots of logic to attempt to avoid information
leakage for something that may never happen.
BUG=v8:2778
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/22962009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Observation in the normal case (Object.observe, default accept types, one observer) now allocates fewer objects and unobservation no longer needs to scan and splice an InternalArray -- making the combined speed of observe/unobserve about 200% faster.
This patch implements the following optimizations:
-objectInfo is initially created without any connected objects or arrays. The first observer is referenced directly by objectInfo, and when a second observer is added, changeObservers converts to a mapping of callbackPriority->observer, which allows for constant time registration/de-registration.
-observer.accept and objectInfo.performing are conceptually the same data-structure. This is now directly represented as an abstract "TypeMap" which can later be optimized to be a smi in common cases, (e.g: https://codereview.chromium.org/19269007/).
-objectInfo observers are only represented by an object with an accept typeMap if the set of accept types is non-default
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/19541010
Patch from Rafael Weinstein <rafaelw@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16629 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Observation in the normal case (Object.observe, default accept types, one observer) now allocates fewer objects and unobservation no longer needs to scan and splice an InternalArray -- making the combined speed of observe/unobserve about 200% faster.
This patch implements the following optimizations:
-objectInfo is initially created without any connected objects or arrays. The first observer is referenced directly by objectInfo, and when a second observer is added, changeObservers converts to a mapping of callbackPriority->observer, which allows for constant time registration/de-registration.
-observer.accept and objectInfo.performing are conceptually the same data-structure. This is now directly represented as an abstract "TypeMap" which can later be optimized to be a smi in common cases, (e.g: https://codereview.chromium.org/19269007/).
-objectInfo observers are only represented by an object with an accept typeMap if the set of accept types is non-default
R=rossberg@chromium.org
Committed: https://code.google.com/p/v8/source/detail?r=16343
Review URL: https://codereview.chromium.org/19541010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16539 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Observation in the normal case (Object.observe, default accept types, one observer) now allocates fewer objects and unobservation no longer needs to scan and splice an InternalArray -- making the combined speed of observe/unobserve about 200% faster.
This patch implements the following optimizations:
-objectInfo is initially created without any connected objects or arrays. The first observer is referenced directly by objectInfo, and when a second observer is added, changeObservers converts to a mapping of callbackPriority->observer, which allows for constant time registration/de-registration.
-observer.accept and objectInfo.performing are conceptually the same data-structure. This is now directly represented as an abstract "TypeMap" which can later be optimized to be a smi in common cases, (e.g: https://codereview.chromium.org/19269007/).
-objectInfo observers are only represented by an object with an accept typeMap if the set of accept types is non-default
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/19541010
Patch from Rafael Weinstein <rafaelw@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16343 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
