http://codereview.chromium.org/8462010/diff/1/src/arm/macro-assembler-arm.cc File src/arm/macro-assembler-arm.cc (right):
http://codereview.chromium.org/8462010/diff/1/src/arm/macro-assembler-arm.cc#newcode1267 src/arm/macro-assembler-arm.cc:1267: // The exception is expected in eax. On 2011/11/11 09:43:13, fschneider wrote:
Should be r0 for arm.
Thanks. Silly that it was right and I changed it :) http://codereview.chromium.org/8462010/diff/1/src/arm/macro-assembler-arm.cc#newcode1309 src/arm/macro-assembler-arm.cc:1309: // Compute the handler entry address and jump to it. The handler table is On 2011/11/10 19:01:04, Vyacheslav Egorov wrote:
Seems this code can be shared between throw and throw uncatchable.
Yeah, good idea. Done. http://codereview.chromium.org/8462010/diff/1/src/objects.h File src/objects.h (right): http://codereview.chromium.org/8462010/diff/1/src/objects.h#newcode4063 src/objects.h:4063: static const int kHandlerTableOffset = kRelocationInfoOffset + kPointerSize; On 2011/11/10 19:01:04, Vyacheslav Egorov wrote:
I think this makes Code's header 64 bytes (with 28 bytes of padding)
on ia32. That's disappointing. I guess we could later choose to move this into the deoptimization data to save the padding at the cost of an extra indirection when throwing. http://codereview.chromium.org/8462010/diff/1/src/parser.cc File src/parser.cc (right): http://codereview.chromium.org/8462010/diff/1/src/parser.cc#newcode496 src/parser.cc:496: int NextHandlerIndex() { return next_handler_index_++; } On 2011/11/10 19:01:04, Vyacheslav Egorov wrote:
Maybe call it AllocateHandlerIndex()?
I would not expect side-effects from function called NextHandlerIndex.
I can see that, but I was following the style of NextMaterializedBlahBlahBlah just above. And AllocateMaterializedLiteralIndex is an eyeful. Since those materialized literal lines are already 78 characters long, I'm a-gonna keep it this way :) http://codereview.chromium.org/8462010/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
