Fix hidden properties to ignore [[Extensible]].

The [[Extensible]] property prevented the very first hidden property
from being added. If any hidden property was added to the object before
preventing extension, adding subsequent hidden properties would have
succeed however.

R=svenpanne@chromium.org
BUG=v8:2034
TEST=mjsunit/regress/regress-2034

Review URL: https://chromiumcodereview.appspot.com/9844025

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@11202 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Reduce initial boot-up memory use.  This is an other attempt at what
http://codereview.chromium.org/9179012 was trying to achieve.  This
time I am going for 80% of the benefit with around 5% of the complexity.

It works by reducing the size of the first page in each space.  Unlike the
previous change there is no attempt to grow pages, we just allocate more
full-sized pages when we need more memory.  For this reason the first pages are
not quite as small (compare
http://codereview.chromium.org/9179012/diff/1/src/snapshot.h with the changes
in spaces.cc in this cl):  We want to be able to do a little bit of allocation
before we have to add a full-sized page to the space.
Review URL: https://chromiumcodereview.appspot.com/9950048

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@11203 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
MIPS: Minor optimization in RegExpMacroAssemblerMIPS::CheckBitInTable.

This was suggested by Erik Corry related to the following issue:
http://codereview.chromium.org/9968032/
Regexp: Improve the speed that we scan for an initial point where a non-anchored
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: https://v8.googlecode.com/svn/branches/bleeding_edge@11204 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Merge commit 'f20b1723108cbc96553c98ce80300b1ef6c2eef2' into hj-dev-kalmard
MIPS: Regexp: Improve the speed that we scan for an initial point

Port r11204 (f20b1723).

Original commit message:

Regexp: Improve the speed that we scan for an initial point where a non-anchored
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.
Change ASSERT(kind() == FUNCTION) to ASSERT_EQ(FUNCTION, kind()).

R=mstarzinger@chromium.org

Review URL: https://chromiumcodereview.appspot.com/9958062

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@11205 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
MIPS: RegExp: Add support for table-based character class code generation.   This is a commit of http://codereview.chromium.org/9968032/ for Daniel Kalmar

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@11206 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Merge remote branch 'v8/bleeding_edge' into hj-dev-kalmard
[MIPS] Removed duplicated regexp code.

This was present as an artifact after the previous merge.