the code object's instructions.
This allows us to find a code object using just the pc. This approach
uses a cache (PcToCodeCache) to make sure we don't continuously have
to iterate heap pages.
This change eliminates the need for cooking and uncooking of stack frames.
Review URL: http://codereview.chromium.org/3226014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5369 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
separate JS stack.
In exception handling, we need to be able to compare addresses into
the JavaScript portion of the stack with the address of a C++ handler
on the stack. Since the stacks are separate on the simulator, we need
a JavaScript stack address corresponding to a C++ try catch handler in
order to perform valid address comparisons.
On the simulator, we now link the C++ try catch handlers indirectly
through the JS stack and use the JS stack indirection address for
comparisons.
JS C++
handler
[C++ address] <------ next_
\
\
\----> handler
[C++ address] <------ next_
On actual hardware the C++ try catch handlers continue to be directly
linked.
BUG=http://code.google.com/p/v8/issues/detail?id=271
Review URL: http://codereview.chromium.org/360004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3228 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of individual changes:
- Added infrastructure for custom stub caching.
- Push the code object onto the stack in exit calls instead of a
debug/non-debug marker.
- Remove the DEBUG_EXIT frame type.
- Add a new exit stub generator for API getters.
Review URL: http://codereview.chromium.org/330017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3130 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
My assumption that log initialization happens somewhere near the stack's bottom is true for V8's sample shell but isn't true for Chromium, causing many otherwise valid stack addresses to be thrown out. The solution proposed is to save stack pointer value for the outermost JS function in ThreadLocalTop similar to c_entry_fp.
Implemented only for IA-32. Currently I'm not dealing with profiling on ARM and x86-64 anyway.
Review URL: http://codereview.chromium.org/112082
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2086 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact.
Review URL: http://codereview.chromium.org/115756
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix exception propagation problem where undefined was returned instead
of an empty handle in case of an exception. This problem can break
C++ programs that are not interested in catching exceptions and just
want to propagate them out by testing for empty handles.
The issue is that exceptions are not rescheduled if they are
externally caught. Externally caught exceptions have to be
rescheduled if there is a JavaScript frame on the way to the C++ frame
that holds the external handler.
A couple of tests will fail on the ARM simulator because the simulator
has separate stacks for C++ and JavaScript. I have marked the tests
as failing only on the simulator.
Review URL: http://codereview.chromium.org/56105
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1657 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of an empty handle in case of an exception. This problem can break
C++ programs that are not interested in catching exceptions and just
want to propagate them out by testing for empty handles.
The issue is that exceptions are not rescheduled if they are
externally caught. Externally caught exceptions have to be
rescheduled if there is a JavaScript frame on the way to the C++ frame
that holds the external handler.
Review URL: http://codereview.chromium.org/43070
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1487 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
that the exception stored in the TryCatch is not cleared as that was the
cause of the regression.
So the actual difference to http://codereview.chromium.org/8101 is:
Index: src/top.h
===================================================================
--- src/top.h (revision 576)
+++ src/top.h (working copy)
@@ -154,10 +154,6 @@
if (has_pending_exception()) {
thread_local_.external_caught_exception_ =
thread_local_.pending_external_caught_exception_;
- } else {
- if (thread_local_.try_catch_handler_ != NULL) {
- thread_local_.try_catch_handler_->Reset();
- }
}
thread_local_.pending_external_caught_exception_ = false;
}
@@ -312,14 +308,14 @@
};
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@593 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changed the catcher_ field to a boolean value and renamed it. Modified the
propagation of the external caught exception to also clear the current
TryCatch if there is no exception as it might hold an exception which has
been bypassed by code in a finally block.
Minor formatting changes to a test.
Review URL: http://codereview.chromium.org/8102
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@576 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
report the exception when they happen in the try block and not as previously
when re-thrown after execution of the finally block. There is no longer any
message generated by re-throw.
Added test cases for various combinations of try/catch/finally with throw in
different places.
Added a regression directory to the messages tests which is processed by the
test runner.
Added regression tests for the specific bugs fixed.
Runs all the test suites.
BUG=73
BUG=75
Review URL: http://codereview.chromium.org/8050
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@565 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
