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);
http://codereview.chromium.org/6592007/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
