Thanks for the comments. Left some replies.
https://codereview.chromium.org/1010883002/diff/40001/src/objects-inl.h
File src/objects-inl.h (right):
https://codereview.chromium.org/1010883002/diff/40001/src/objects-inl.h#newcode767
src/objects-inl.h:767: // a handler table array.
On 2015/03/17 10:21:22, Yang wrote:
Maybe we want to introduce a special fixed array map? Then again that
would just
be for debugging and assertions.
Acknowledged. As discussed offline, Benedikt and I were thinking about
moving this table into the code object itself at some point. So I would
vote for having the table be minimally intrusive for now, if you are
fine with that.
https://codereview.chromium.org/1010883002/diff/40001/src/objects.cc
File src/objects.cc (right):
https://codereview.chromium.org/1010883002/diff/40001/src/objects.cc#newcode8540
src/objects.cc:8540: for (int i = 0; i < length(); i += kRangeEntrySize)
{
On 2015/03/17 10:21:22, Yang wrote:
The handler table should be sorted by start_offset (which we could
also assert).
We could end the loop early if start_offset > pc_offset, right?
Acknowledged. Unfortunately the start offsets are not strictly
increasing because the handler index is given out by the parser in "post
parse tree"-ish order whereas the code is generated in "pre AST"-ish
order. So for nested try-catch or try-finally statement the order is
almost guaranteed to be screwed up. I am totally up for optimizing this
later once we have measurements of the overhead that these lookup
operations incur.
https://codereview.chromium.org/1010883002/diff/40001/src/objects.cc#newcode8547
src/objects.cc:8547: if (start_offset < innermost_start) continue;
On 2015/03/17 10:21:22, Yang wrote:
This assumes that for nested try-catch, the start_offset of the inner
try-catch
is always larger than the start_offset of the outer one. Is this
guaranteed for
all platforms?
Acknowledged. Yes, this should hold on all architectures, because every
nested try-catch or try-finally statement will at least push the context
register before it enters the try-block. The DCHECK one line above tries
to guard that. Let me know if you can think of a better way to guard
that, or particular test cases that we should add.
As per offline discussion, there are tests in mjsunit/try.js that have
tightly nested try-blocks. I verified that there is one where the start
offsets are as close together as possible (i.e.
return_from_nested_catch) and one where the end offsets are as close
together as possible (i.e. break_from_nested_catch) already.
https://codereview.chromium.org/1010883002/diff/40001/src/runtime/runtime-generator.cc
File src/runtime/runtime-generator.cc (right):
https://codereview.chromium.org/1010883002/diff/40001/src/runtime/runtime-generator.cc#newcode70
src/runtime/runtime-generator.cc:70: }
On 2015/03/17 09:41:26, wingo wrote:
Hoo, nasty stuff. ACK though :)
Acknowledged. Yeah, it's nasty. But my campaign against full-codegen
keeping track of the operand stack height at expression level will find
it's end once do-expressions become reality. Because then even I would
agree that keeping track of stack height statically is unavoidable. Best
of luck to the poor soul having to implement that, I hope it won't be
me. :)
https://codereview.chromium.org/1010883002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
