Port r11336 (6dd4e844)
Original commit message:
Implement rudimentary module linking.
Constructs the (generally cyclic) graph of module instance objects
and populates their exports. Any exports other than nested modules
are currently set to 'undefined' (but already present as properties).
Details:
- Added new type JSModule for instance objects: a JSObject carrying a context.
- Statically allocate instance objects for all module literals (in parser 8-}).
- Extend interfaces to record and unify concrete instance objects,
and to support iteration over members.
- Introduce new runtime function for pushing module contexts.
- Generate code for allocating, initializing, and setting module contexts,
and for populating instance objects from module literals.
Currently, all non-module exports are still initialized with 'undefined'.
- Module aliases are resolved statically, so no special code is required.
- Make sure that code containing module constructs is never optimized
(macrofy AST node construction flag setting while we're at it).
- Add test case checking linkage.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10035028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11374 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r11331 (bd7843a0)
Original commit message:
Refactoring of code generation for declarations, in preparation for modules.
Do proper dispatch on declaration type instead of mingling together
different code generation paths. Once we add more declaration forms,
this is more scalable.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10119017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11372 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r11278 (e5dc7ebd).
Original commit message:
Skip canonicalization check in LStoreKeyedFastDoubleElement when it is not needed:
- if value is a result of integer32 to double conversion (can't be NaN);
- if value was loaded from fast double backing store (already canonicalized).
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10071004
Patch from Daniel Kalmar <kalmard@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11366 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Constructs the (generally cyclic) graph of module instance objects
and populates their exports. Any exports other than nested modules
are currently set to 'undefined' (but already present as properties).
Details:
- Added new type JSModule for instance objects: a JSObject carrying a context.
- Statically allocate instance objects for all module literals (in parser 8-}).
- Extend interfaces to record and unify concrete instance objects,
and to support iteration over members.
- Introduce new runtime function for pushing module contexts.
- Generate code for allocating, initializing, and setting module contexts,
and for populating instance objects from module literals.
Currently, all non-module exports are still initialized with 'undefined'.
- Module aliases are resolved statically, so no special code is required.
- Make sure that code containing module constructs is never optimized
(macrofy AST node construction flag setting while we're at it).
- Add test case checking linkage.
Baseline: http://codereview.chromium.org/9722043/R=svenpanne@chromium.org,mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9844002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11336 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
Do proper dispatch on declaration type instead of mingling together
different code generation paths. Once we add more declaration forms,
this is more scalable.
In separate steps, I'd like to (1) clean up the logic for DeclareGlobal,
and (2) try to reduce the special handling of the name function var if
possible.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9704054
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The stats data have only count field at the moment.
A constantly growing array of integers also can be a reason of a leak.
Ans we have to have a way to detect such kind of leaks.
Drive by fix:
FindObject and AddEntry were replaced with FindEntry/FindOrAddEntry pair.
BUG=none
TEST=HeapSnapshotObjectsStats
Review URL: https://chromiumcodereview.appspot.com/10086004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11327 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
MinGW-w64 uses the rcx register for the first argument. Unlike MSVC, it does not require preparing a slot for the result handle on the stack and putting a pointer to it in the rcx register.
BUGS=v8:2026
TEST=cctest/test-api
Review URL: https://chromiumcodereview.appspot.com/9959050
Patch from Jonathan Liu <net147@gmail.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
