This change allows hydrogen instructions to keep track of instructions
that dominate certain side-effects (GVN flags) in the hydrogen graph. We
use the GVN pass to keep track of side-effects because accurate flags
are already in place.
It also adds a new side-effect (kChangesNewSpacePromotion) indicating
whether an instruction can cause a GC and have objects be promoted to
old-space. An object allocated in new-space is sure to stay on paths not
having said side-effect.
R=erik.corry@gmail.com
TEST=mjsunit/compiler/inline-construct
Review URL: https://chromiumcodereview.appspot.com/10031031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11270 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes processing of WeakMaps so that value entries on an evacuation
candidate are correctly recorded in the slots buffer. We didn't pass the
correct slot into the backing hashtable while visiting values.
Also the live bytes counter for large object space pages was not reset
correctly when incremental marking is aborted.
R=vegorov@chromium.org
BUG=v8:2060
TEST=cctest/test-weakmaps/Regress2060
Review URL: https://chromiumcodereview.appspot.com/10034010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11264 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This will give us the ability to keep entries_ list sorted by id.
And based on that fact we will be able to use it for:
1) GetNodeById method and drop sorted version of entries list in HeapSnapshot;
2) building heap stats;
3) doing the fill stage instead of second iteration over heap.
BUG=none
TEST=none
R=yurys
Review URL: https://chromiumcodereview.appspot.com/10031032
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11259 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r11010 (1daa81bc).
MIPS-specific changes:
-register codes and registers are defined using a macro to avoid redundancy
-renamed s8_fp to fp, removed the "fp" alias
-removed kSavedValueRegister (found by check-static-initializers.sh)
Original commit message:
Landing for pliard@chromium.org: Remove static initializers in v8.
This change includes two CLs by pliard@chromium.org:
1. http://codereview.chromium.org/9447052/ (Add CallOnce() and simple LazyInstance implementation):
Note that this implementation of LazyInstance does not handle global destructors (i.e. the lazy instances a
This CL was initially reviewed on codereview.appspot.com:
http://codereview.appspot.com/5687064/
2. http://codereview.chromium.org/9455088/ (Remove static initializers in v8):
This CL depends on CL 9447052 (adding CallOnce and LazyInstance).
It is based on a patch sent by Digit.
With this patch applied, we have only one static initializer left (in atomicops_internals_x86_gcc.cc). This
This CL also modifies the presubmit script to check the number of static initializers.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9689069
Patch from Daniel Kalmar <kalmard@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11241 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The template system converts the actual struct type to an array of chars.
Make sure the alignment is kept by the compiler.
This fixes a lot of serialization-related HW tests, for example cctest test-serialize/Serialize.
BUG=
TEST=cctest test-serialize
Review URL: https://chromiumcodereview.appspot.com/9702114
Patch from Daniel Kalmar <kalmard@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11240 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The two tests (S8.5_A2.1, S8.5_A2.2) fail on ia32 Linux and simulators.
They do pass on ARM and MIPS hardware under Linux, and on the other
supported platforms and architectures.
They are now marked PASS || FAIL_OK.
BUG=
TEST=test262/S8.5_A2.1, test262/S8.5_A2.2
Review URL: https://chromiumcodereview.appspot.com/9959146
Patch from Paul Lind <plind44@gmail.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11230 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
regexp can match by using a Boyer-Moore-like table. This is done by identifying
non-greedy non-capturing loops in the nodes that eat any character one at a time.
For example in the middle of the regexp /foo[\s\S]*?bar/ we find such a loop.
There is also such a loop implicitly inserted at the start of any non-anchored
regexp.
When we have found such a loop we look ahead in the nodes to find the set of
characters that can come at given distances. For example for the regexp
/.?foo/ we know that there are at least 3 characters ahead of us, and the sets
of characters that can occur are [any, [f, o], [o]]. We find a range in the
lookahead info where the set of characters is reasonably constrained. In our
example this is from index 1 to 2 (0 is not constrained). We can now look 3
characters ahead and if we don't find one of [f, o] (the union of [f, o] and
[o]) then we can skip forwards by the range size (in this case 2).
For Unicode input strings we do the same, but modulo 128.
We also look at the first string fed to the regexp and use that to get a hint
of the character frequencies in the inputs. This affects the assessment of
whether the set of characters is 'reasonably constrained'.
We still have the old lookahead mechanism, which uses a wide load of multiple
characters followed by a mask and compare to determine whether a match is
possible at this point.
Review URL: http://codereview.chromium.org/9965010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11204 ce2b1a6d-e550-0410-aec6-3dcde31c8c00