Addressed comments in a new patch set.

https://codereview.chromium.org/110203002/diff/20001/src/full-codegen.h
File src/full-codegen.h (right):

https://codereview.chromium.org/110203002/diff/20001/src/full-codegen.h#newcode934
src/full-codegen.h:934: static void RemoveStackCheck(CompilationInfo*
info);
On 2013/12/17 15:27:55, titzer wrote:
On 2013/12/10 11:22:04, Yang wrote:
> On 2013/12/09 14:49:28, titzer wrote:
> > And why does this one take a CompilationInfo? Does it remove all
checks, or
> just
> > one?
>
> This removes only the one added in AddStackCheck. All the necessary
information
> are in the compilation info, so I though passing that would be
cleaner.

I think Add and Remove should be symmetric, and neither should take a
CompilationInfo, which is an indirection to the stuff needed for the
operation.

Made the signatures symmetrical.

https://codereview.chromium.org/110203002/diff/20001/src/runtime.cc
File src/runtime.cc (right):

https://codereview.chromium.org/110203002/diff/20001/src/runtime.cc#newcode8314
src/runtime.cc:8314: ASSERT(!function->is_compiled());
On 2013/12/17 15:27:55, titzer wrote:
On 2013/12/10 11:22:04, Yang wrote:
> On 2013/12/09 14:49:28, titzer wrote:
> > Why?
>
> I guess we would guard that this is only called from the builtin. I
think we
can
> remove this.

In general, I think neither CompileOptimized nor CompileUnoptimized
should
depend on the prior state of the function. They only establish these
invariants
upon exit:

CompileUnoptimized:
   function has code.
   function has unoptimized code if no code existed before.

CompileOptimized:
   function has code.
   function has optimized code if it was already available / generated
successfully.
   if concurrent compilation is on, then there might be a new
concurrent
compilation job running in the background now.


Added asserts at the end guarding those exit invariants.

https://codereview.chromium.org/110203002/diff/20001/src/runtime.cc#newcode8334
src/runtime.cc:8334: if (!function->shared()->is_compiled()) {
On 2013/12/17 15:27:55, titzer wrote:
On 2013/12/10 11:22:04, Yang wrote:
> On 2013/12/09 14:49:28, titzer wrote:
> > I don't think we want this check. IIRC that forces all functions
to be first
> > compiled unoptimized and then recompiled.
>
> I think that is intentional. I merely inlined AllowOptimization
here. I would
> like to keep this refactoring from changing the behavior to avoid
running into
> possible performance regressions. We could experiment with this
later.

Add a TODO. I still think it's an unnecessary restriction, but it is
OK for now.

Done.

https://codereview.chromium.org/110203002/

--
--
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/groups/opt_out.

Reply via email to