operation. I have another version of this change that does not remove the
special inline caches for difference sized strings. The other version is ever
so slightly faster, but the nice thing about this version is that it removes
253 lines of code.
Review URL: http://codereview.chromium.org/8187
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@603 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
accesses (eg, parameters, locals, and the expression stack elements)
and mutation (pushes and pops) go through the virtual frame.
The frame initially contains no state, and directly emits instructions
in the obvious way. It is not currently used for deferred code.
Review URL: http://codereview.chromium.org/7076
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@489 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 evaluated with an extra element on the stack, which needs
to be taken into account when breaking and continuing.
I'll clean up the code and add an abstraction for manipulating
the break stack height in a future CL -- I want to try to get
rid of the separate local variable we keep around for the "state"
when running in a finally block.
Review URL: http://codereview.chromium.org/5625
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@400 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
canonicalize maps for object literals. JSON objects
with the same set of properties names will then
share the same map.
This reduces the amount of generated code associated
with object literals.
- Added a flag canonicalize_object_literal_maps.
(default true)
- Changed the format of a function's literal array.
Only the global context is now stored in the literal prefix.
Review URL: http://codereview.chromium.org/4078
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@371 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
upper case. Moved it into the RelocInfo class together with the associated
is_xxx functions. Renamed is_xxx to IsXxx in the process.
Removed the exit_js_frame mode as it was no longer used.
Patch Set 2 renames RELOC_MODE_COUNT to NUMBER_OF_MODES and fixes a couple of lint errors.
Review URL: http://codereview.chromium.org/3186
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@354 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
until a possible debug break location is reached. Currently this is call sites
with calls to code objects and JS return. Source position information in the
code therefore no longer refers to the "first" instruction generated for a
given source position (which was not the case defered code anyway) but to the
first break location after that source position was passed (again defered code
always start with source position information). This doesn't make a difference
for the debugger as it will always be stopped only at debug break locations.
However, this makes the life of the peep-hole optimizer much easier as many
oportunities for posh/pop eliminations where previosly blocked by relocation
information already written to the code object.
Two types of source positions are still collected. Statement positions indicate
the position of the start of the statement leading to this code and (plain)
positions indicate other places typically call sites to help indicate current
position in backtraces. The two different types of positions are also used to
distinguish between step next and step in.
Runs all the tests (including debugger tests) as before.
Moved the checking for the FLAG_debug_info to one place.
I will do the same changes to the ARM codegenerator in a seperate changelist.
Review URL: http://codereview.chromium.org/2957
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@335 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
