- 18 Mar, 2011 3 commits
-
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7271 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7269 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
Review URL: http://codereview.chromium.org/6685088 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7268 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Dec, 2010 1 commit
-
-
sgjesse@chromium.org authored
objectprint=on (defaults to off) option (which defines OBJECT_PRINT). 2. Added the ability to print objects to a specified file instead of just stdout. 3. Added a use_verbose_printer flag (true by default) to allow some object printouts to be less verbose when the flag is false. 4. Fixed a bug in VSNPrintF() where it can potentially write into an empty char vector. Patch by Mark Lam from Hewlett-Packard Development Company, LP Review URL: http://codereview.chromium.org/5998001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6080 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Nov, 2009 1 commit
-
-
sgjesse@chromium.org authored
The different length string types was used to encode the string length and the hash in one field. This is now split into two fields one for length and one for hash. The hash field still encodes the array index of the string if it has one. If an array index is encoded in the hash field the string length is added to the top bits of the hash field to avoid a hash value of zero. On 32-bit this causes an additional 4 bytes to be used for all string objects. On 64-bit this will be half on average dur to pointer alignment. Review URL: http://codereview.chromium.org/436001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3350 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Oct, 2009 1 commit
-
-
sgjesse@chromium.org authored
* The maximum length of short and medium sized strings is now derived from other constants. * Remove the redundant String part of their names. Review URL: http://codereview.chromium.org/347002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3162 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Sep, 2009 1 commit
-
-
mikhail.naganov@gmail.com authored
The profile is taken together with constructors profile. In theory, it should represent a complete heap graph. However, this takes a lot of memory, so it is reduced to a more compact, but still useful form. Namely: - objects are aggregated by their constructors, except for Array and Object instances, that are too hetereogeneous; - for Arrays and Objects, initially every instance is concerned, but then they are grouped together based on their retainer graph paths similarity (e.g. if two objects has the same retainer, they are considered equal); Review URL: http://codereview.chromium.org/200132 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2903 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Aug, 2009 1 commit
-
-
whesse@chromium.org authored
Review URL: http://codereview.chromium.org/160452 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2605 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Jul, 2009 1 commit
-
-
kmillikin@chromium.org authored
1. The tables array allocated in the CompilationSubCache constructor was never deallocated. Fixed by adding destructor. 2. The buffer allocated in one of the constructors of the NoAllocationStringAllocator was never deallocated. It seems that this class sometimes owns the buffer (if it allocated one itself) and sometimes doesn't (if it was passed one). Simple fix is to remove the offending constructor which was never used anyway. Review URL: http://codereview.chromium.org/155917 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2520 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Jul, 2009 1 commit
-
-
ager@chromium.org authored
The abstractions have led to bugs because it looks like descriptor streams are GC safe but they are not. I have moved the descriptor stream helper functions to descriptor arrays and I find most of the code just as readable now as it was before. Review URL: http://codereview.chromium.org/149458 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2428 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 May, 2009 1 commit
-
-
mikhail.naganov@gmail.com authored
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
-
- 16 Apr, 2009 1 commit
-
-
iposva@chromium.org authored
a reason to stack allocate large chunks of stack space. - Runtime_GetCFrames used to allocate a frame size of 52040 bytes. - PreallocatedMemoryThread::Run used to allocate 32784 bytes. - Fixed StringStream overflow conditions. Review URL: http://codereview.chromium.org/67197 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1729 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Nov, 2008 1 commit
-
-
christian.plesner.hansen@gmail.com authored
Review URL: http://codereview.chromium.org/12427 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Nov, 2008 1 commit
-
-
lrn@chromium.org authored
Fix for non-empty assertion in debug mode (string representation of empty arguments is a single space, not an empty string). git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@733 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Oct, 2008 1 commit
-
-
feng@chromium.org authored
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
-
- 15 Oct, 2008 1 commit
-
-
iposva@chromium.org authored
constructor in the JSObject. This removes the need to allocate a properties array if the object is never assigned any extra properties. Review URL: http://codereview.chromium.org/7341 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@501 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Sep, 2008 1 commit
-
-
christian.plesner.hansen@gmail.com authored
Vector<...> in more places to be sure that buffers have a length associated with them. Review URL: http://codereview.chromium.org/1940 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@283 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Sep, 2008 1 commit
-
-
christian.plesner.hansen@gmail.com authored
Added presubmit step to check copyright. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@242 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Jul, 2008 1 commit
-
-
kasper.lund authored
Added support for storing JavaScript stack traces in a stack allocated buffer to make it visible in shallow core dumps. Controlled by the --preallocate-message-memory flag which is disabled by default. git-svn-id: http://v8.googlecode.com/svn/trunk@7 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jul, 2008 1 commit
-
-
christian.plesner.hansen authored
git-svn-id: http://v8.googlecode.com/svn/trunk@2 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-