LGTM for the one-word patch itself, but the surrounding code has to be
clarified
(see my comment).
http://codereview.chromium.org/7741041/diff/1/src/x64/regexp-macro-assembler-x64.cc
File src/x64/regexp-macro-assembler-x64.cc (right):
http://codereview.chromium.org/7741041/diff/1/src/x64/rege
+lrn
http://codereview.chromium.org/7741041/diff/1/src/x64/regexp-macro-assembler-x64.cc
File src/x64/regexp-macro-assembler-x64.cc (right):
http://codereview.chromium.org/7741041/diff/1/src/x64/regexp-macro-assembler-x64.cc#newcode1190
src/x64/regexp-macro-assembler-x64.cc:1190: *return_addres
On 2011/08/26 13:41:03, Vyacheslav Egorov wrote:
+lrn
http://codereview.chromium.org/7741041/diff/1/src/x64/regexp-macro-assembler-x64.cc
File src/x64/regexp-macro-assembler-x64.cc (right):
http://codereview.chromium.org/7741041/diff/1/src/x64/regexp-macro-assembler-x64.cc#newcode1190
src
LGTM.
You shouldn't need crankshaft, just a compacting GC that moves the calling
Code
object. I'm not sure there is a good way to do that consistently, though.
http://codereview.chromium.org/7741041/
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
Isn't the issue that, as far as I can see, this part of code is only called
when the we switch to the profiler thread in the middle of regexp code and
in there trigger GC? If crankshaft is disabled, profiler doesn't run and the
regexp code won't be interrupted and we won't jump into this part of co
There can be other reasons for being interrupted, e.g., preemption by
another thread that causes a GC. Anything that causes Code to move
should trigger this.
/L
On Fri, Aug 26, 2011 at 18:12, Yang Guo wrote:
> Isn't the issue that, as far as I can see, this part of code is only called
> when the
