Port revision 6934 and 6993 (plus fix from 6935) to the 3.0 branch.

Port revision 6934 (plus fix from 6935) and refactoring in revision 6993 to the 3.0 branch.

Committed: http://code.google.com/p/v8/source/detail?r=7156

[Erik Corry, 2011-02-25 12:42:02]

LGTM, but please talk to Mads before committing.

[Mads Ager (chromium), 2011-02-28 08:11:20]

No reason for another handle abstraction. We can escape handles to the outer
handle scope. Let's iterated on this on bleeding_edge today before merging to
the branch.

http://codereview.chromium.org/6592007/diff/1/src/handles.h
File src/handles.h (right):

http://codereview.chromium.org/6592007/diff/1/src/handles.h#newcode96
src/handles.h:96: // A handle-scope based variable. The value stored in the
variable can change
Please do not introduce a new abstraction for this. We can easily escape a
handle to an outer scope already. We should do another iteration on
bleeding_edge before merging this.

http://codereview.chromium.org/6592007/diff/1/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/6592007/diff/1/src/runtime.cc#newcode7894
src/runtime.cc:7894: class ArrayConcatVisitor {
Should this BASE_EMBEDDED. This should not be allocated and stored since it has
members that depend on the current handle scope.

http://codereview.chromium.org/6592007/diff/1/src/runtime.cc#newcode7956
src/runtime.cc:7956: HandleCell<NumberDictionary> slow_storage(
Just use a normal handle and escape the handle from the inner handle scope.

http://codereview.chromium.org/6592007/diff/1/src/runtime.cc#newcode7963
src/runtime.cc:7963: slow_storage =
slow_storage = GetNewHandle().EscapeFrom(&loop_scope);

[Lasse Reichstein, 2011-03-09 12:43:06]

Please recheck.

[Erik Corry, 2011-03-09 14:06:42]

LGTM

[Lasse Reichstein, 2011-03-10 14:07:45]

FYI.