When loaded scripts are requested this cache is filled with all the script objects in the heap. Hereafter its content is kept in sync with the active scripts in the heap through the notifications of new scripts compiled and by using weak handles to get notified when a script is collected.
Through the tracking of collected scripts the debugger event OnScriptCollected have been added to notify a debugger that a script previously returned through the scripts command is no longer in use.
Make the ComputeIntegerHash globally available.
Moved clearing of the mirror cache to when debugger is really left. Previously recursive invocations of the debugger cause the mirror cache to be cleared causing handles to become either stale or reference other objects.
Review URL: http://codereview.chromium.org/115462
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1988 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The object delivered to the debug message handler contains additional information on the current break handling the messages.
Clients which require just JSON message parsing can simply get the JSON using the GetJSON message on the message object to still have the previous behaviour.
NewMessageHangler(const v8::Debug::Message& message) {
v8::String::Value val(message.GetJSON());
OldMessageHandler(Vector<uint16_t>(const_cast<uint16_t*>(*val), val.length()));
}
Refactored some of the debugger code to use internal handles instead of API handles. Also changed Object to JSObject is some places.
The access to the active context when the break occurred is still not implemented. I will add this in a new CL, as this one is quite big already.
Review URL: http://codereview.chromium.org/99122
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1811 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The debug message thread was introduced to make it possible to have the message handler callback be called from a different thread than the thread running V8 where the debug event occoured, but it never had any practical use, and prevents providing information to the message handler which is only available from the V8 thread.
In the future any thread decoupling will have do be done by the embedder.
This also removes the queue used for outbound messages.
Renamed the class Message to CommandMessage as it is only used for debugger commands from the client. Related message queue classes has also been renamed.
Review URL: http://codereview.chromium.org/93118
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1788 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For keyed IC loads setting a break point now ensures that the inlined code is not used. When the break point is set the inlined map check is changed to fail causing the inlined code not to be used but the IC to be called. As long at the break point is set the map check will stay invalid.
Review URL: http://codereview.chromium.org/87025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1756 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
ENABLE_DEBUGGER_SUPPORT is enabled by default unless it is on Android platform.
On Android platform, it can also enabled by passing -DENABLE_DEBUGGER_SUPPORT flag to the compiler.
This should not affect any existing build (I hope, cross my fingers) except the build in real Android environment (in other word, it only affects me now).
There are lot of room for code refactoring in stead of using #ifdef all over the place. I will leave this to v8 folks.
Review URL: http://codereview.chromium.org/77035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1745 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The generic step-in mechanism floods the function called with break points to ensure a break is hit when entering the function. This generic mechanism was also used for function.apply. The code for function.apply contains a keyed load IC which was patched when stepping into function.apply. However function.apply enteres an internal frame not a JavaScript frame. This caused the logic for returning from the break in function.apply to fail as it forced a jump to the IC on the top JavaScript frame. The top JavaScript frame was the frame for the function calling function.apply not the frame for the apply function. Now returning from the break point in the keyed load IC in the apply code caused a jump to the code for the call IC for the function calling function.apply in the first place. Not a pretty sight.
Step-in now handles function.apply as a separate case where the actual JavaScript function called through apply is flodded with breakpoints instead of the function.apply function.
BUG=269
BUG=8210@chromium.org
Review URL: http://codereview.chromium.org/63055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add a semaphore for accessing debugger varaibles which can be changed from a different thread. This is mainly the debug message handler which can be set to NULL to disconnect the debugger.
Control the unloading of the debugger from the V8 thread. Before the debugger unload was called from the thread setting the debug message handler to NULL. This was not safe as this involves calling into V8. This change handles the unloading of the debugger either when entering a debugger event and the debugger was disconnected while the debugger was not active or when leaving the debugger and the debugger was disconnected while the debugger was active.
Add a flag to avoid unloading the debugger if debugger code is used by the application for other purposes than debugging.
Added tests for clearing the debug message handler.
Review URL: http://codereview.chromium.org/56102
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1648 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The message handler function set through the debugger API is normally called in a different thread than the V8 thread where execution is stopped due to debugger event. This change adds an option to the API for specifying that the message handler should be called directly from the V8 thread. For an application like Chrome where thread dispatching is already in place this makes more sense.
Add an option to the message handler debugger API to process messages in the thread where V8 is running instead of posting it to a queue for processing on a additional thread.
Review URL: http://codereview.chromium.org/42643
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1627 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- String traversal test data (now in a zone)
- Debug message thread (now joined on exit)
- Threading test threads (now joined on exit)
- Changed message tests framework to cope with valgrind
Also, fixed a bug where we'd try to delete stack-allocated objects
when tearing down v8. Good times.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1622 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
During bind and listen socket errors are now handled. If the listen socket is occoupied the agent will retry its bind operation until success or shutdown.
Added orderly shutdown of the debugger agent both with and without a client connected.
Review URL: http://codereview.chromium.org/50007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1552 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This makes it possible to remote debuggers to just add commands to the queue without having to request a break as well. As soon as any JavaScript executes the debugger commands will be processed and the response send to the remote debugger.
Currently hide this behind a flag (--debugger-auto-break) as the current command line debugger in Chrome is not designed for this new behaviour, whereas the new Chrome developer tools will use it.
Review URL: http://codereview.chromium.org/42173
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1508 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The debugger agent listens on a TCP/IP port for a remote debugger connection. When such a connection is established the debuger JSON protocol is communicated between the agent the the remote debugger. The messages containing the JSON protocol has a RFC-822 like header with a Content-Length field and with the body containing the JSON in UTF-8 encoding.
The D8 shell has option --debugger-agent to start the debugger agent.
Review URL: http://codereview.chromium.org/27355
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1405 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add the ability to have the host embedding V8 receive a callback in the V8 thread while V8 is processing a debug callback. When V8 is processing a debug callback the thread where V8 is executing is sitting in a tight loop processing debug commands until the continue command has been executed. In some embedding situations it is beneficial to be able to call back into the embedding host from the thread where V8 is sitting. The might have functions which needs to be called to complement the JavaScript debugging.
Using the uint16_t array to pass a void* is a temporary hack.
Review URL: http://codereview.chromium.org/20491
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1318 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added a number of handle scopes to the debugger code to keep handles local to the function using them.
Fixed SetDebugEventListener to actually unregister when passed a NULL pointer. Previously this NULL pointer was wrapped in a Proxy.
BUG=1242702
Review URL: http://codereview.chromium.org/21347
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1269 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The debugger compile events (BeforeCompile and AfterCompile) have not been used by any V8 debuggers lately and where actually not working any more. Added the correct information to the compile event.
Added a simple 'trace compile' command to the developer shell for testing.
Added a test for compile evnets.
Review URL: http://codereview.chromium.org/21076
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1230 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
it is assigned a numeric handle. Handles are used to make a 1:1
correspondence between objects and mirrors. Currently the mirrors are
cached in a JavaScript array and when creating a mirror this cache is
checked to see if a mirror already exists for the object. This cache is
cleared when leaving the debugger.
Changed the serialization format to take advantage of these handles. When
an object is serialized referenced objects are represented just by their
handle id serialized as '{ref:<handle>}'. During serialization the
referenced handles are collected and the serializer can provide a
serialization of all the referenced objects.
Removed the special handling of array properties. Indexed properties and
the length property are now rendered as named properties in the
serialization.
Removed the special serialization handling of RegExp properties. The
properties 'source', 'global', 'ignoreCase' and 'multiline' are serialized
with the rest of the properties.
Changed a lot of tests to handle the changed format.
Review URL: http://codereview.chromium.org/18092
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1093 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changed the serialization format to take advantage of these handles. When an object is serialized referenced objects are represented just by their handle id serialized as '{ref:<handle>}'. During serialization the referenced handles are collected and the serializer can provide a serialization of all the referenced objects.
Removed the special handling of array properties. Indexed properties and the length property are now rendered as named properties in the serialization.
Removed the special serialization handling of RegExp properties. The properties 'source', 'global', 'ignoreCase' and 'multiline' are serialized with the rest of the properties.
Changed a lot of tests to handle the changed format.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1078 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
