Remove kind field from StackHandler.

Remove kind field from StackHandler.

This relands commit 96f79568a926966ebcf0685bf9adc947f4e1fbff.

This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.

There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.

With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.

R=yangguo@chromium.org

Committed: https://crrev.com/15f8213809a57c2a163b500a732c9ffe5160a41a
Cr-Commit-Position: refs/heads/master@{#27263}

[Michael Starzinger, 2015-03-17 19:11:26]

mstarzinger@chromium.org changed reviewers:
+ yangguo@chromium.org

[Michael Starzinger, 2015-03-17 19:14:23]

Notes about the patch sets in this CL:
Patch Set #1: Pure reland, no other changes.
Patch Set #2: Fix debugger-pause-on-promise-rejection.html

[Yang, 2015-03-18 10:10:01]

lgtm.

[Michael Starzinger, 2015-03-18 10:11:48]

The CQ bit was checked by mstarzinger@chromium.org

[commit-bot: I haz the power, 2015-03-18 10:11:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/997213003/20001

[commit-bot: I haz the power, 2015-03-18 10:19:10]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-18 10:19:27]

Patchset 2 (id:??) landed as
https://crrev.com/15f8213809a57c2a163b500a732c9ffe5160a41a
Cr-Commit-Position: refs/heads/master@{#27263}

[rmacnak, 2015-04-21 01:40:22]

On 2015/03/18 10:19:27, I haz the power (commit-bot) wrote:
> Patchset 2 (id:??) landed as
> https://crrev.com/15f8213809a57c2a163b500a732c9ffe5160a41a
> Cr-Commit-Position: refs/heads/master@{#27263}

This change is responsible for a 70% drop in the ParserCombinators benchmark.
Chrome is now slower than Firefox. What's the motivation for table-based lookup
of exception handlers?

[Sven Panne, 2015-04-21 07:20:40]

On 2015/04/21 01:40:22, rmacnak wrote:
> On 2015/03/18 10:19:27, I haz the power (commit-bot) wrote:
> > Patchset 2 (id:??) landed as
> > https://crrev.com/15f8213809a57c2a163b500a732c9ffe5160a41a
> > Cr-Commit-Position: refs/heads/master@{#27263}
> 
> This change is responsible for a 70% drop in the ParserCombinators benchmark.
> Chrome is now slower than Firefox. What's the motivation for table-based
lookup
> of exception handlers?

I only had a quick look at the benchmark, and I'm not sure if we really want to
care about its performance: It seems to use exceptions heavily during normal
program execution (to do the backtracking for alternatives/star), and this is
quite unusual and not necessary (see http://dl.acm.org/citation.cfm?id=5288).
Our usual approach is: Optimize for normal control flow and don't care about
performance when an exception is actually thrown. (Well, we delay the
construction of the stack trace, but that's about it.)

Perhaps there's some low-hanging fruit to improve things, but otherwise I guess
not much will happen...

[Michael Starzinger, 2015-04-21 09:20:02]

On 2015/04/21 01:40:22, rmacnak wrote:
> On 2015/03/18 10:19:27, I haz the power (commit-bot) wrote:
> > Patchset 2 (id:??) landed as
> > https://crrev.com/15f8213809a57c2a163b500a732c9ffe5160a41a
> > Cr-Commit-Position: refs/heads/master@{#27263}
> 
> This change is responsible for a 70% drop in the ParserCombinators benchmark.
> Chrome is now slower than Firefox. What's the motivation for table-based
lookup
> of exception handlers?

Hey Ryan!

Thanks for reaching out. The motivation behind having a table-based lookup of
exception handlers, is that it allows us to deoptimize from within a try-block
as well as OSR into a try-block compiled by TurboFan. So far any try-catch
construct would prevent optimization of the entire function. This CL in
particular was one of several in preparation of handling try-catch constructs in
TurboFan.

Note that the non-exceptional path (i.e. try-catch constructs without a throw
happening) are not negatively impacted by these changes (they are in fact a
little bit more efficient now). Only the exceptional path in cases where we
could before determine not to need a exception-message, but now create an
exception-message, has become more expensive.