- 11 Mar, 2014 2 commits
-
-
rossberg@chromium.org authored
- Merge LanguageMode and StrictModeFlag enums - Make harmony-scoping depend only on strict mode - Free some bits on the way - Plus additional clean-up and renaming R=ulan@chromium.org BUG= Review URL: https://codereview.chromium.org/181543002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19800 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/177683002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19799 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 Feb, 2014 1 commit
-
-
mvstanton@chromium.org authored
The problem was that the debugger didn't expect that a JSFunction could have a GlobalContext, which it can with harmony scoping. BUG=343928 R=yangguo@chromium.org LOG=N Review URL: https://codereview.chromium.org/183103003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19576 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Feb, 2014 1 commit
-
-
rafaelw@chromium.org authored
This patch generalizes Object.observe callbacks and promise resolution into a FIFO queue called a "microtask queue". It also exposes new V8 API which exposes the microtask queue to the embedder. In particular, it allows the embedder to -schedule a microtask (EnqueueExternalMicrotask) -run the microtask queue (RunMicrotasks) -control whether the microtask queue is run automatically within V8 when the last script exits (SetAutorunMicrotasks). R=dcarney@chromium.org, rossberg@chromium.org, dcarney, rossberg, svenpanne BUG= Review URL: https://codereview.chromium.org/154283002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Jan, 2014 1 commit
-
-
dslomov@chromium.org authored
Replaced symbolic names with correct JS name (byte -> int8, unsigned int -> uint32 etc). Using macros to scrap the boilerplate BUG= R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/145133013 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18835 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 Nov, 2013 1 commit
-
-
rossberg@chromium.org authored
Based on prototype at https://github.com/rossberg-chromium/js-promise which informed the latest spec draft version at https://github.com/domenic/promises-unwrapping/blob/master/README.md Activated by --harmony-promises. Feature complete with respect to the draft spec, plus the addition of .when and .deferred methods. Final naming and other possible deviations from the current draft will hopefully be resolved soon after the next TC39 meeting. This CL also generalises the Object.observe delivery loop into a simplistic microtask loop. Currently, all observer events are delivered before invoking any promise handler in a single fixpoint iteration. It's not clear yet what the final semantics is supposed to be (should there be a global event ordering?), but it will probably require a more thorough event loop abstraction inside V8 once we get there. R=dslomov@chromium.org, yhirano@chromium.org BUG= Review URL: https://codereview.chromium.org/64223010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18113 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Nov, 2013 1 commit
-
-
svenpanne@chromium.org authored
The main change is that a bit has been added to array buffers to signal that the backing store has to be freed when the buffer dies. BUG=316359 LOG=Y R=yangguo@chromium.org Review URL: https://codereview.chromium.org/82763005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18003 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Nov, 2013 2 commits
-
-
danno@chromium.org authored
Revert 17966, 17965 also as collateral damage: Embed trigonometric lookup table. Due to Heapcheck and valgrind failures that are not yet fixed. TBR=svenpanne@chromium.org Review URL: https://codereview.chromium.org/80513004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17981 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
This removes tons of architecture-specific code and makes it easy to experiment with other pseudo-RNG algorithms. The crankshafted code is extremely good, keeping all things unboxed and doing only minimal checks, so it is basically equivalent to the handwritten code. When benchmarks are run without parallel recompilation, we get a few percent regression on SunSpider's string-validate-input and string-base64, but these benchmarks run so fast that the overall SunSpider score is hardly affected and within the usual jitter. Note that these benchmarks actually run even faster when we don't crankshaft at all on the main thread (the regression is not caused by bad code, it is caused by Crankshaft needing a few hundred microsecond for compilation of a trivial function). Luckily, when parallel recompilation is enabled, i.e. in the browser, we see no regression at all! R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/68723002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17955 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Sep, 2013 1 commit
-
-
titzer@chromium.org authored
Add OptimizedCodeList and DeoptimizedCodeList to native contexts. Both lists are weak. This makes it possible to find optimized code that is not referred to by any function, but still needs to be deoptimized. It obsoletes the weak deoptimizing code list in the deoptimizer data and generally simplifies the process of deoptimizing code. BUG= R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/23444029 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16530 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Sep, 2013 1 commit
-
-
dcarney@chromium.org authored
R=svenpanne@chromium.org BUG= Review URL: https://codereview.chromium.org/23729006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16489 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Jun, 2013 1 commit
-
-
dslomov@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/17153011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15269 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Jun, 2013 1 commit
-
-
adamk@chromium.org authored
R=adamk@chromium.org, rossberg@chromium.org Review URL: https://codereview.chromium.org/15504002 Patch from Rafael Weinstein <rafaelw@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 May, 2013 1 commit
-
-
danno@chromium.org authored
Improves NavierStokes by about 5% R=ulan@chromium.org Review URL: https://codereview.chromium.org/15014020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14630 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 May, 2013 1 commit
-
-
wingo@igalia.com authored
ES3 specified that functions created via Function() would have enumerable prototypes, unlike function literals. For this reason, V8 has always had two prototypes for functions: "function_map" for literals, and "function_instance_map" for "function instances": those functions created by Function(). However, since 2009 or so, both maps have been the same! Both have had writable, non-enumerable prototypes. Moreover, ES5 changed to specify that function instances would have non-enumerable prototypes. This patch removes the separate maps for function instances in sloppy and strict mode. R=mstarzinger@chromium.org TEST=mjsunit/function-prototype BUG= Review URL: https://codereview.chromium.org/14829005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14619 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 May, 2013 1 commit
-
-
wingo@igalia.com authored
Generators now box their return values in object literals of the form { value: VAL, done: DONE } where DONE is false for yield expressions, and true for return statements. BUG=v8:2355 TEST=mjsunit/harmony/generators-iteration R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/13870007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14563 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 May, 2013 1 commit
-
-
dslomov@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/14657003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14517 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2013 1 commit
-
-
dslomov@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/14195034 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14476 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Apr, 2013 1 commit
-
-
dslomov@chromium.org authored
R=rossberg@chromium.org BUG= Review URL: https://codereview.chromium.org/13958007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14438 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Apr, 2013 1 commit
-
-
rossberg@chromium.org authored
* src/contexts.h: * src/bootstrapper.cc (InitializeExperimentalGlobal): Make generator meta-objects, and store maps for constructing generator functions and their prototypes. * src/factory.h: * src/factory.cc (MapForNewFunction): New helper. (NewFunctionFromSharedFunctionInfo): Use the new helper. * src/heap.cc (AllocateFunctionPrototype, AllocateInitialMap): For generators, allocate appropriate prototypes and maps. * src/code-stubs.h: * src/arm/code-stubs-arm.h: * src/arm/full-codegen-arm.h: * src/ia32/code-stubs-ia32.h: * src/ia32/full-codegen-ia32.h: * src/x64/code-stubs-x64.h: * src/x64/full-codegen-x64.h: Allow fast closure creation for generators, using the appropriate map. * test/mjsunit/harmony/builtins.js: Add a special case for GeneratorFunctionPrototype.prototype.__proto__. BUG= TEST=mjsunit/harmony/generators-runtime Review URL: https://codereview.chromium.org/13192004 Patch from Andy Wingo <wingo@igalia.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14236 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Mar, 2013 1 commit
-
-
rossberg@chromium.org authored
(qua last week's TC39) Specifically: - Install Symbol constructor function on the global object. - Adjust code generation for typeof. - Remove IsSymbol built-in, IS_SYMBOL macro now defined using typeof. - Remove hack that allowed symbols as constructor results, and some other special cases. - Remove symbol_delegate and GetDelegate function. - Extend ToBoolean stub to handle symbols. - Extend ToNumber to return NaN on symbols. - Poison symbol's toString function, and thereby ToString on symbols. R=mstarzinger@chromium.org BUG=v8:2158 Review URL: https://codereview.chromium.org/12957004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Mar, 2013 1 commit
-
-
rossberg@chromium.org authored
- Add --harmony-symbols flag. - Add Symbol constructor; allow symbols as (unreplaced) return value from constructors. - Introduce %CreateSymbol and %_IsSymbol natives and respective instructions. - Extend 'typeof' code generation to handle symbols. - Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols. - Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method. - Extend Object.prototype.toString to recognise symbols. Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object). (Baseline CL: https://codereview.chromium.org/12223071/) R=mstarzinger@chromium.org BUG=v8:2158 Review URL: https://codereview.chromium.org/12296026 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Dec, 2012 1 commit
-
-
rossberg@chromium.org authored
For strict-mode eval, this requires _disabling_ lazy parsing of inner functions, because we need to collect their free variables to do allocation for the eval scope properly. R=mstarzinger@chromium.org BUG=v8:2315 Review URL: https://codereview.chromium.org/11438042 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13161 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Nov, 2012 1 commit
-
-
rossberg@chromium.org authored
Modules now have their own local scope, represented by their own context. Module instance objects have an accessor for every export that forwards access to the respective slot from the module's context. (Exports that are modules themselves, however, are simple data properties.) All modules have a _hosting_ scope/context, which (currently) is the (innermost) enclosing global scope. To deal with recursion, nested modules are hosted by the same scope as global ones. For every (global or nested) module literal, the hosting context has an internal slot that points directly to the respective module context. This enables quick access to (statically resolved) module members by 2-dimensional access through the hosting context. For example, module A { let x; module B { let y; } } module C { let z; } allocates contexts as follows: [header| .A | .B | .C | A | C ] (global) | | | | | +-- [header| z ] (module) | | | +------- [header| y ] (module) | +------------ [header| x | B ] (module) Here, .A, .B, .C are the internal slots pointing to the hosted module contexts, whereas A, B, C hold the actual instance objects (note that every module context also points to the respective instance object through its extension slot in the header). To deal with arbitrary recursion and aliases between modules, they are created and initialized in several stages. Each stage applies to all modules in the hosting global scope, including nested ones. 1. Allocate: for each module _literal_, allocate the module contexts and respective instance object and wire them up. This happens in the PushModuleContext runtime function, as generated by AllocateModules (invoked by VisitDeclarations in the hosting scope). 2. Bind: for each module _declaration_ (i.e. literals as well as aliases), assign the respective instance object to respective local variables. This happens in VisitModuleDeclaration, and uses the instance objects created in the previous stage. For each module _literal_, this phase also constructs a module descriptor for the next stage. This happens in VisitModuleLiteral. 3. Populate: invoke the DeclareModules runtime function to populate each _instance_ object with accessors for it exports. This is generated by DeclareModules (invoked by VisitDeclarations in the hosting scope again), and uses the descriptors generated in the previous stage. 4. Initialize: execute the module bodies (and other code) in sequence. This happens by the separate statements generated for module bodies. To reenter the module scopes properly, the parser inserted ModuleStatements. R=mstarzinger@chromium.org,svenpanne@chromium.org BUG= Review URL: https://codereview.chromium.org/11093074 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Nov, 2012 1 commit
-
-
svenpanne@chromium.org authored
Review URL: https://codereview.chromium.org/11365224 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12945 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Nov, 2012 1 commit
-
-
svenpanne@chromium.org authored
Fixed visibility attribute for GetPointerFromInternalField Heavy cleanup of the external pointer API. Review URL: https://codereview.chromium.org/11359125 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12911 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Nov, 2012 1 commit
-
-
rossberg@chromium.org authored
This CL has two parts: the first is the logic itself, whereby each observer callback is assigned a "priority" number the first time it's passed as an observer to Object.observe(), and that priority is used to determine the order of delivery. The second part invokes the above logic as part of the API, when the JS stack winds down to zero. Added several tests via the API, as the delivery logic isn't testable from a JS test (it runs after such a test would exit). Review URL: https://codereview.chromium.org/11266011 Patch from Adam Klein <adamk@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 Nov, 2012 1 commit
-
-
rossberg@chromium.org authored
In more detail: - Set observation bit for observed objects (and make NormalizedMapCache respect it). - Mutation of observed objects is always delegated from ICs to runtime. - Introduce JS runtime function for notifying generated changes. - Invoke this function in the appropriate places (including some local refactoring). - Inclusion of oldValue field is not yet implemented, nor element properties. Also, shortened flag to --harmony-observation. R=verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/11347037 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12867 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Nov, 2012 1 commit
-
-
svenpanne@chromium.org authored
Added highly efficient Object::SetAlignedPointerInInternalField and Object::GetAlignedPointerFromInternalField functions for 2-byte-aligned pointers. Their non-aligned counterparts Object::GetPointerFromInternalField and Object::SetPointerInInternalField are now deprecated utility functions. External is now a true Value again, with New/Value/Cast using a JSObject with an internal field containing a Foreign. External::Wrap, and External::Unwrap are now deprecated utility functions. Added Context::GetEmbedderData and Context::SetEmbedderData. Deprecated Context::GetData and Context::SetData, these are now only wrappers to access internal field 0. Added highly efficient Context::SetAlignedPointerInEmbedderData and Context::GetAlignedPointerFromEmbedderData functions for 2-byte-aligned pointers. Review URL: https://codereview.chromium.org/11190050 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Sep, 2012 1 commit
-
-
ulan@chromium.org authored
BUG=140191 R=svenpanne@chromium.org,mkwst@chromium.org Review URL: https://chromiumcodereview.appspot.com/10837358 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12525 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 Aug, 2012 1 commit
-
-
rossberg@chromium.org authored
They are yet unused; actual allocation of global lexical bindings in these contexts is implemented in a separate follow-up CL. R=svenpanne@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/10876067 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12384 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Aug, 2012 2 commits
-
-
rossberg@chromium.org authored
in preparation for global lexical scope. R=mstarzinger@chromium.org BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/10832365 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12335 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
in anticipation of the upcoming lexical global scope. Mostly automatised as: for FILE in `egrep -ril "global[ _]?context" src test/cctest` do echo $FILE sed "s/Global context/Native context/g" <$FILE >$FILE.0 sed "s/global context/native context/g" <$FILE.0 >$FILE.1 sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2 sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3 sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE rm $FILE.[0-9] done R=mstarzinger@chromium.org BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/10832342 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Jul, 2012 1 commit
-
-
rossberg@chromium.org authored
Specifically: - In parser, check that all exports are defined. - Move JSModule allocation from parser to scope resolution. - Move JSModule linking from full codegen to scope resolution. - Implement module accessors for exported value members. - Allocate module contexts statically along with JSModules (to allow static linking), but chain them when module literal is evaluated. - Make module contexts' extension slot refer to resp. JSModule (makes modules' ScopeInfo accessible from context). - Some other tweaks to context handling in general. - Make any code containing module literals (and thus embedding static references to JSModules) non-cacheable. This enables accessing module instance objects as expected. Import declarations are a separate feature and do not work yet. R=mstarzinger@chromium.org BUG=v8:1569 TEST= Review URL: https://chromiumcodereview.appspot.com/10690043 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 May, 2012 1 commit
-
-
danno@chromium.org authored
R=jkummerow@chromium.org TEST=jkummerow@chromium.org Review URL: https://chromiumcodereview.appspot.com/10170030 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11636 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Apr, 2012 1 commit
-
-
rossberg@chromium.org authored
I also discovered that our treatment of const declarations is inconsistent when inside a global eval under 'with' (i.e., when created by DeclareContextSlots). That is, var x; eval("const x = 9") and var x; eval("with({}) const x = 9") differ (the former assigns 9, the latter throws). This appears to be an oversight from earlier changes to our const semantics (the latter shouldn't throw either). Fixing this is a separate issue, though (and one that doesn't seem quite worthwhile). R=mstarzinger@chromium.org BUG=v8:1991,80591 TEST= Review URL: https://chromiumcodereview.appspot.com/10067010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11333 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Feb, 2012 1 commit
-
-
rossberg@chromium.org authored
Module definitions are not compiled or otherwise executed yet. Toplevel module identifiers are bound but never initialized. R=kmillikin@chromium.org,mstarzinger@google.com BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/9401008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10759 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Feb, 2012 1 commit
-
-
danno@chromium.org authored
BUG=none TEST=3d-cube faster Review URL: https://chromiumcodereview.appspot.com/9235007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10583 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 Jan, 2012 1 commit
-
-
danno@chromium.org authored
BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/9073007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10523 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 Dec, 2011 1 commit
-
-
danno@chromium.org authored
R=whesse@chromium.org BUG=v8:1878 TEST=test/mjsunit/regress/regress-1878.js Review URL: http://codereview.chromium.org/9016041 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10306 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-