The performance of Array::concat is critical of jQuery benchmark from
http://www.dromaeo.com. Our current implementation in JavaScript is very
generic and is several times slower than JSC and SpiderMonkey.
Re-implement Array::concat in C++ to take advantage of underlying implementation
details. This cuts dom-travesal-jquery execution time by half.
We may want to move Array specific implementation into a separate source file,
say jsarray.cc.
Review URL: http://codereview.chromium.org/7990
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If a map has descendents in the map transition tree that are alive,
it is kept. Only maps such that they and all their descendants
have no live objects are collected. This happens in mark-sweep and
mark-compact garbage collections.
Review URL: http://codereview.chromium.org/8099
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@601 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Changed WeakReferenceCallback to take a Persistent<Value> instead of
a Persistent<Object>.
- Removed Message::GetUnderline and Message::GetScriptData.
- Added Value::IsDate, Date::Cast and Date::Value.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@564 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
- Reduce it to half size if the pattern is ASCII, saving on initialization
- If pattern is ASCII and subject is not, any non-ASCII char can cause a
full pattern-length shift, even if we haven't indexed the entire pattern.
- Use memset to initialize buffer in the common case where the pattern is
shorter than the max significant suffix limit.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@519 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Patch from Erik Corry to separate BM-algoritm into special case
functions. Also changes condition for bailing out of simple search.
* Added simple search with no bailout for very short patterns.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@513 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
to be insufficient.x
Changed order of tests in loop in simple text search.
Changed limit on pattern length for when we pick simple search.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@496 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
