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
1.) When a back-merged patch applied at an offset, ignore the "Hunk #1 succeeded at ..." lines instead of printing a scary warning.
2.) When push-to-trunk was not called with "-c /path/to/chrome/src", explicitly ask for the path to help discoverability of the feature.
3.) Correctly convert "BUG=chromium:123" to "(Chromium issue 123)" in the pre-made ChangeLog entry.
Review URL: https://chromiumcodereview.appspot.com/10073010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11321 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r11306 (36b58f7).
Original commit message:
This passes the isolate through to API callback functions so that it is
available through AccessorInfo and Arguments. This allows bindings to
avoid unnecessary TLS lookups to retrieve the current isolate.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10083001
Patch from Daniel Kalmar <kalmard@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11319 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r11282 (bd2ab07).
Patch by Daniel Kalmar.
Original commit message:
Some GWT compiled code results in array access that has a heap number (e.g. -0)
as an index. Until now this would result in a generic IC.
For example:
a[-0] === a[0] or
a[0.25 * 4] === a[1]
This change detects heap numbers that are representable as a smi
and converts them. As a result we can still use the fast keyed monomorphic
ICs. Optimized code already handles keyed access with a double-key efficiently.
As a result the frame rate on the reported benchmark improves by roughly 2x.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10068012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11318 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
