The approach in this change is to handle the unwrapping/wrapping of the global object transparently with respect to the JS implementation of Object.observe. An alternate approach would be to add a runtime method like %IsJSGlobalProxy and %UnwrapJSGlobalProxy, but it seems ugly to give JS (even implementation JS) access to the unwrapped global.
BUG=v8:2409
Review URL: https://codereview.chromium.org/11414094
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13142 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This changes how FunctionTemplate interprets a Signature that specifies
compatible receivers and arguments. Only the hidden prototype chain will
be considered when searching for compatible receivers. This prevents
JavaScript from modifying the inheritance relationship set up by the
embedder.
R=rossberg@chromium.org
BUG=v8:2268
TEST=cctest/test-api
Review URL: https://codereview.chromium.org/11308197
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13131 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Modules now have their own local scope, represented by their own context.
Module instance objects have an accessor for every export that forwards
access to the respective slot from the module's context. (Exports that are
modules themselves, however, are simple data properties.)
All modules have a _hosting_ scope/context, which (currently) is the
(innermost) enclosing global scope. To deal with recursion, nested modules
are hosted by the same scope as global ones.
For every (global or nested) module literal, the hosting context has an
internal slot that points directly to the respective module context. This
enables quick access to (statically resolved) module members by 2-dimensional
access through the hosting context. For example,
module A {
let x;
module B { let y; }
}
module C { let z; }
allocates contexts as follows:
[header| .A | .B | .C | A | C ] (global)
| | |
| | +-- [header| z ] (module)
| |
| +------- [header| y ] (module)
|
+------------ [header| x | B ] (module)
Here, .A, .B, .C are the internal slots pointing to the hosted module
contexts, whereas A, B, C hold the actual instance objects (note that every
module context also points to the respective instance object through its
extension slot in the header).
To deal with arbitrary recursion and aliases between modules,
they are created and initialized in several stages. Each stage applies to
all modules in the hosting global scope, including nested ones.
1. Allocate: for each module _literal_, allocate the module contexts and
respective instance object and wire them up. This happens in the
PushModuleContext runtime function, as generated by AllocateModules
(invoked by VisitDeclarations in the hosting scope).
2. Bind: for each module _declaration_ (i.e. literals as well as aliases),
assign the respective instance object to respective local variables. This
happens in VisitModuleDeclaration, and uses the instance objects created
in the previous stage.
For each module _literal_, this phase also constructs a module descriptor
for the next stage. This happens in VisitModuleLiteral.
3. Populate: invoke the DeclareModules runtime function to populate each
_instance_ object with accessors for it exports. This is generated by
DeclareModules (invoked by VisitDeclarations in the hosting scope again),
and uses the descriptors generated in the previous stage.
4. Initialize: execute the module bodies (and other code) in sequence. This
happens by the separate statements generated for module bodies. To reenter
the module scopes properly, the parser inserted ModuleStatements.
R=mstarzinger@chromium.org,svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/11093074
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- perform CPU profiler sampling in the sampler thread as we used to;
- skip sampling in the sampling thread if processing thread is running;
- only install SIGPROF handler when CPU profiling is enabled.
BUG=v8:2364
Review URL: https://codereview.chromium.org/11231002
Patch from Sergey Rogulenko <rogulenko@google.com> and Andrey Kosyakov <caseq@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12985 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To preserve ordering guarantees during end-of-turn delivery, Object.deliverChangeRecords needs to remove the delivered-to observer from the list of active observers.
The added test demonstrates this behavior.
Review URL: https://codereview.chromium.org/11410046
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12951 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL has two parts: the first is the logic itself, whereby each observer callback is assigned
a "priority" number the first time it's passed as an observer to Object.observe(), and that
priority is used to determine the order of delivery.
The second part invokes the above logic as part of the API, when the JS stack winds down to
zero.
Added several tests via the API, as the delivery logic isn't testable from a JS test
(it runs after such a test would exit).
Review URL: https://codereview.chromium.org/11266011
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This requires adding a new JSObject to the strong root list and populating it from
object-observe.js. The main other change is that we now directly use ObjectHashTable
from JS rather than using WeakMap, since using the latter would end up leaking whichever
Context initialized that observation state.
Added a test via the API showing that different contexts all end up working on the same state.
Review URL: https://codereview.chromium.org/11274014
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12873 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
