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.