Thanks for the comments.
http://codereview.chromium.org/8357010/diff/1/src/ic.cc File src/ic.cc (right): http://codereview.chromium.org/8357010/diff/1/src/ic.cc#newcode1897 src/ic.cc:1897: On 2011/10/20 10:12:23, Vyacheslav Egorov wrote:
add empty line
Done. http://codereview.chromium.org/8357010/diff/1/src/stub-cache.cc File src/stub-cache.cc (right): http://codereview.chromium.org/8357010/diff/1/src/stub-cache.cc#newcode935 src/stub-cache.cc:935: return reinterpret_cast<Code*>(code); On 2011/10/20 10:12:23, Vyacheslav Egorov wrote:
I wonder how this can be callled during marking phase.
Also marking phase does not corrupt maps anymore so we should convert
to checked
casts here.
Good question, and good suggestion to switch to checked casts. I'll investigate. http://codereview.chromium.org/8357010/diff/1/src/stub-cache.cc#newcode1056 src/stub-cache.cc:1056: MaybeObject* StubCache::TryComputeCallMiss(int argc, On 2011/10/20 10:12:23, Vyacheslav Egorov wrote:
I wonder why ComputeCallMiss is not defined in terms on
TryComputeCallMiss?
Are we going to kill TryComputeCallMiss once the stub compiler is
fully
handlified? If so please state this in the comments.
Yeah, Try... will be eliminated next. I'll comment it. For this change, I just wanted ComputeCallMiss to be able to do GC at a finer granularity than wrapping CALL_HEAP_FUNCTION around TryComputeCallMiss (it has two possible allocation failures). http://codereview.chromium.org/8357010/diff/1/src/stub-cache.h File src/stub-cache.h (right): http://codereview.chromium.org/8357010/diff/1/src/stub-cache.h#newcode800 src/stub-cache.h:800: MUST_USE_RESULT MaybeObject* CompileCallField(JSObject* object, On 2011/10/20 10:12:23, Vyacheslav Egorov wrote:
Should not we prefix unhandlified functions' names with Try?
Maybe. They're going to be changed next, so we'll be left with the non-Try version. For now, we just wanted to make the smallest impact. (The only reason I had Try... was because I couldn't overload on the argument type there.) http://codereview.chromium.org/8357010/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
