- 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
-
- 07 Dec, 2010 3 commits
-
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5922 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5921 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5920 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Sep, 2010 1 commit
-
-
erik.corry@gmail.com authored
This one has been approved by the 64 bit compiler in MSVC 2005 so I hope it also passes the 2008 version. The --max-new-space-size option is now in kBytes. The --max-old-space-size option is now in MBytes. Some issues remain with 64 bit heaps and the counters. See http://code.google.com/p/v8/issues/detail?id=887 Review URL: http://codereview.chromium.org/3573005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5559 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Sep, 2010 2 commits
-
-
erik.corry@gmail.com authored
be done from Windows where the compiler is stricter about truncating changes. Review URL: http://codereview.chromium.org/3454035 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5545 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
Fix test after 64 bit heap size change. Review URL: http://codereview.chromium.org/3432032 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5543 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Jul, 2010 1 commit
-
-
kaznacheev@chromium.org authored
The static ScopeInfo members moved into this class. The new class is named ScopeInfoObject which I am not proud of, better ideas are very welcome. Also got rid of the sentinels in the serialized scope info which saves 3 words per function and is not slower. Review URL: http://codereview.chromium.org/2908009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Jul, 2010 1 commit
-
-
kaznacheev@chromium.org authored
The scope info is now stored in a FixedArray referenced from SharedFunctionInfo. Review URL: http://codereview.chromium.org/2918001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5056 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Dec, 2009 1 commit
-
-
kasperl@chromium.org authored
fixed contexts slots. Take this into account when using the new, fast context creation path to avoid allocating too many slots (wasteful). Review URL: http://codereview.chromium.org/501148 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Jun, 2009 1 commit
-
-
bak@chromium.org authored
Review URL: http://codereview.chromium.org/141038 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2230 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
-
- 24 Feb, 2009 1 commit
-
-
ager@chromium.org authored
surrounding context to figure out if the variable could be global. If the variable could be global we check context extension objects at runtime and use a global LoadIC if no variables have been introduced by eval. Fix crash bug when loading function arguments from inside eval. The shadowed variable in the DYNAMIC_LOCAL case does not rewrite to a slot in that case. Review URL: http://codereview.chromium.org/28027 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1348 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Feb, 2009 3 commits
-
-
ager@chromium.org authored
Not sure what happened, but my revert did not get everything out. Fixing the problem instead. The issue was using tmp instead of context in two places. TBR=kasperl Review URL: http://codereview.chromium.org/20459 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1303 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ager@chromium.org authored
to fix now. TBR=kasperl Review URL: http://codereview.chromium.org/20458 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1302 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ager@chromium.org authored
introduced by eval. In the cases where calls to eval have not introduced any variables, we do not need to perform a runtime call. Instead, we verify that the context extension objects have not been created and perform a direct load. Not implemented for ARM yet and the scope resolution code could use some better abstractions. I'd like to do that in a separate changelist. Review URL: http://codereview.chromium.org/20419 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1298 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Jan, 2009 1 commit
-
-
ager@chromium.org authored
act as if they have no properties in their prototype chains. This fixes V8 issue 193: http://code.google.com/p/v8/issues/detail?id=193. Review URL: http://codereview.chromium.org/18709 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1132 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 Nov, 2008 1 commit
-
-
olehougaard authored
Review URL: http://codereview.chromium.org/12673 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@860 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Nov, 2008 2 commits
-
-
ager@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
olehougaard authored
TBR=ager Review URL: http://codereview.chromium.org/11565 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@821 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Oct, 2008 1 commit
-
-
kasperl@chromium.org authored
use safe casting operations to slot access on contexts when possible. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@588 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
-
- 12 Sep, 2008 1 commit
-
-
deanm@chromium.org authored
This is a new static flag system, designed to have all flags in a central place, and compiled into the binary without requiring static constructors for registration. All flags are moved out of the specific modules and into flags.defs, with different sections for debug, release, etc. The flag variables are always defined. For example, a debug flag in release mode still exists, but is read only and set to the default value. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@296 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
-
- 03 Jul, 2008 1 commit
-
-
christian.plesner.hansen authored
git-svn-id: http://v8.googlecode.com/svn/trunk@2 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-