1. Deferred code: there is a problem.  I have added a call to clear the
deferred code if we hit a stack overflow during compilation.
2. Currently, we unwind all the recursive calls to the code generator by
returning, and a stack overflow just makes subsequent calls to the code
generator return immediately.  So it looks like with the current stack
overflow behavior we're OK.

New change uploaded.

On Wed, Mar 11, 2009 at 02:39, Kasper Lund <[email protected]> wrote:

> I'm not sure if this is good enough yet. What happens if we get an
> exception (stack overflow) while compiling code, but we already have a
> bunch of deferred code stubs that needs processing? Shouldn't we be
> clearing those as well? How about the JumpTargets initialized in the
> code generator - can we ever get a stack overflow or something and not
> get to the Unuse call?
>
> On Wed, Mar 11, 2009 at 10:31 AM,  <[email protected]> wrote:
> > Reviewers: Kasper Lund,
> >
> > Description:
> > Fix issue 268 by explicitly calling Unuse (to deallocate all contained
> > virtual frames) on zone-allocated jump targets.  These include jump
> > targets in AST nodes and the entry and exit targets of deferred code.
> >
> > See http://code.google.com/p/v8/issues/detail?id=268
> >
> >
> > Please review this at http://codereview.chromium.org/42067
> >
> > SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
> >
> > Affected files:
> >  M     src/codegen-arm.cc
> >  M     src/codegen-ia32.cc
> >  M     src/codegen.h
> >  M     src/codegen.cc
> >
> >
> >
>

--~--~---------~--~----~------------~-------~--~----~
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to