lgtm.
There is still something weird about the debugger interaction with the
pipeline,
but willing to take it as is, which is a big improvement.
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/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.
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/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.
https://codereview.chromium.org/110203002/diff/20001/src/runtime.cc#newcode8334
src/runtime.cc:8334: if (!function->shared()->is_compiled()) {
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.
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.
