Moved the registrered debug event listener from the context to a global handle in the Debugger class. Storing it in the context did not make much sense.
Changed a lot of tests to handle the API change.
BUG=1242707
Review URL: http://codereview.chromium.org/19753
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1212 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This can lead to large objects which wastes a lot of space if we normalize properties. We therfore clear the inobject properties when normalizing properties. This is done by adjusting the instance size in the new map and overwriting the inobject properties with a filler.
Review URL: http://codereview.chromium.org/17308
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of the generated code. These can be used by the profiler to
categorize the ticks that occur within generated code and thereby show
more detailed information about where time is spent in generated code.
For instance, this is what the profiler displayed for a simple regexp
benchmark with irregexp-native before:
[JavaScript]:
total nonlib name
87.2% 87.2% RegExp: (?:\w*\W+)*
This is what we can display now:
[JavaScript]:
total nonlib name
87.2% 87.2% RegExp: (?:\w*\W+)*
- 53.0% 56.7% BranchOrBacktrack
- 14.9% 59.8% CheckCharacterLT
- 13.7% 20.4% CheckStackLimit
- 6.7% 6.7% SafeCall
- 2.7% 7.0% CheckCharacterGT
- 2.4% 2.4% SafeReturn
- 2.1% 2.1% LoadCurrentCharacter
- 1.8% 1.8% PushRegister
- 0.9% 0.9% PopRegister
- 0.9% 0.9% AdvanceRegister
- 0.3% 0.3% PopCurrentPosition
- 0.3% 0.3% CheckGreedyLoop
- 0.0% 20.4% PushBacktrack
- 0.0% 22.3% CheckCharacter
- 0.0% 2.4% IfRegisterLT
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Here is a description of the background and design of split window in Chrome and V8:
https://docs.google.com/a/google.com/Doc?id=chhjkpg_47fwddxbfr
This change list splits the window object into two parts: 1) an inner window object used as the global object of contexts; 2) an outer window object exposed to JavaScript and accessible by the name 'window'. Firefox did it awhile ago, here are some discussions: https://wiki.mozilla.org/Gecko:SplitWindow. One additional benefit of splitting window in Chrome is that accessing global variables don't need security checks anymore, it can improve applications that use many global variables.
V8 support of split window:
There are a small number of changes on V8 api to support split window:
Security context is removed from V8, so does related API functions;
A global object can be detached from its context and reused by a new context;
Access checks on an object template can be turned on/off by default;
An object can turn on its access checks later;
V8 has a new object type, ApiGlobalObject, which is the outer window object type. The existing JSGlobalObject becomes the inner window object type. Security checks are moved from JSGlobalObject to ApiGlobalObject. ApiGlobalObject is the one exposed to JavaScript, it is accessible through Context::Global(). ApiGlobalObject's prototype is set to JSGlobalObject so that property lookups are forwarded to JSGlobalObject. ApiGlobalObject forwards all other property access requests to JSGlobalObject, such as SetProperty, DeleteProperty, etc.
Security token is moved to a global context, and ApiGlobalObject has a reference to its global context. JSGlobalObject has a reference to its global context as well. When accessing properties on a global object in JavaScript, the domain security check is performed by comparing the security token of the lexical context (Top::global_context()) to the token of global object's context. The check is only needed when the receiver is a window object, such as 'window.document'. Accessing global variables, such as 'var foo = 3; foo' does not need checks because the receiver is the inner window object.
When an outer window is detached from its global context (when a frame navigates away from a page), it is completely detached from the inner window. A new context is created for the new page, and the outer global object is reused. At this point, the access check on the DOMWindow wrapper of the old context is turned on. The code in old context is still able to access DOMWindow properties, but it has to go through domain security checks.
It is debatable on how to implement the outer window object. Currently each property access function has to check if the receiver is ApiGlobalObject type. This approach might be error-prone that one may forget to check the receiver when adding new functions. It is unlikely a performance issue because accessing global variables are more common than 'window.foo' style coding.
I am still working on the ARM port, and I'd like to hear comments and suggestions on the best way to support it in V8.
Review URL: http://codereview.chromium.org/7366
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@540 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
underlying string representation of the two strings involved.
- Renamed ascii and two byte string classes to sequential ascii and
sequential two byte, and renamed IsAscii and friends to
IsAsciiRepresentation. This is to make a clear distinction between
strings with an ascii/two-byte representation, of which there is
four, and flat sequential ascii/two-byte string.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@474 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
are always odd if the bit-field bits are included.
Modified a couple of debugger tests that relied on the ordering of
elements in descriptor arrays. Descriptor arrays are sorted by
hash-code values, so the order changes if we change the hash code.
Review URL: http://codereview.chromium.org/6489
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@440 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
it for scripts too. In the context of Chromium, this should
have a very positive impact on memory consumption for web apps
that run multiple tabs from the same domain with a lot of the
same JavaScript code.
For now, the cache retirement policy is really simple:
Whenever a mark-sweep collection is started we clear the
cache. This guarantees that this change will not have a
huge negative impact on memory consumption, but it may
not be ideal. We should consider a more sophisticated LRU
scheme.
Review URL: http://codereview.chromium.org/1933
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@270 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The cache is a hashtable that takes String as key and JSFunction as the value.
Caches are cleared before mark-compact GC's.
Currently I don't put caps on cache size, string size, etc.
This cuts date-parse-totfe.js runtime by half.
Review URL: http://codereview.chromium.org/457
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@173 ce2b1a6d-e550-0410-aec6-3dcde31c8c00