* 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}
For the moment, we only pass the global object (the one we are setting up).
A few smaller changes were necessary to avoid failures in
test-object-observe/DontLeakContextOnObserve. Otherwise the global object
would be retained by being context allocated, leading to test failure.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1132513003
Cr-Commit-Position: refs/heads/master@{#28331}
The biggest change is the removal of the map wrapper objects:
we now operate directly on the observation weak map, since there
are already Get/GetOrCreate/Set functions for each info map.
Various other small cleanups as well, including the deletion of
unnecessary forwarding functions and making use of standard macros.
This is a reland of r24972, retaining GetObservationStateJS() to
keep snapshotting working properly.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/663253006
Cr-Commit-Position: refs/heads/master@{#24990}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24990 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The biggest change is the removal of the map wrapper objects: we now operate
directly on the observation weak map, since there are already Get/GetOrCreate/Set
functions for each info map. Various other small cleanups as well, including the
deletion of unnecessary forwarding functions and making use of standard macros.
R=arv@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/686773002
Cr-Commit-Position: refs/heads/master@{#24972}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24972 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The original patch which ensured that Object.observe did allocations in the correct context regressed performance about 12%. This patch gets back most of that (about 11%) by simply returning the correct function which is then directly callable from JS, rather than by making the call from the runtime function. A side-effect is that their implementation is shorter.
LOG=Y
BUG=NONE
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/307543008
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21575 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This avoids the appearence of a leak due to storing a JSObject
as the microtask_state in the strong root list, and allows callers
to call Isolate::RunMicrotasks() without having any v8::Context
available (as at least Blink has interest in doing).
The queue is now a strong root, represented as a FixedArray of JSFunctions
(or empty_fixed_array, if it's empty); it doubles in size when it needs to grow.
The number of elements in the queue is stored in Isolate::pending_microtask_count().
LOG=Y
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/290633010
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21356 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
The intent of these calls was to properly key the WeakMap get/set calls
on the underlying global object, not the proxy, since that is the object
actually being observed. But unwrapping at this layer is unnecessary
since GetIdentityHash will already do the unwrapping (via its call to
GetHiddenProperty).
Also remove the runtime function itself, as these were the only callers,
and remove the now-redundant IS_SPEC_OBJECT() checks from object-observe.js's
MapWrapper type.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/234143002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20740 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
