Move StackGuard::InterruptRequested into StackLimitCheck.

src/json-parser.h

Index: src/json-parser.h
diff --git a/src/json-parser.h b/src/json-parser.h
index 81c83bd1d8aad08f2d49489b79fc7111f5de4879..3ee874930411579ed88fd067237e3cd491f2ddcd 100644
--- a/src/json-parser.h
+++ b/src/json-parser.h
@@ -263,10 +263,10 @@ Handle<Object> JsonParser<seq_one_byte>::ParseJsonValue() {
     return Handle<Object>::null();
   }
 
-  if (isolate_->stack_guard()->InterruptRequested()) {
+  if (stack_check.InterruptRequested()) {
     ExecutionAccess access(isolate_);

[Michael Starzinger, 2015/08/24 14:40:06]

Aehm, are we sure that acquiring the lock here is correct? This will hold on to
the lock while the GC is active. This looks majorly scary to me. The lock should
only be needed to do the interrupt checking, which is done inside
StackGuard::CheckAndClearInterrupt where the lock is acquired explicitly.

[Yang, 2015/08/24 14:50:43]

yup that looks both somewhat wrong and also unnecessary. though i dont think
this will lead to a dead lock. we dont expect an interrupt to trigger during gc.

[Michael Starzinger, 2015/08/24 14:56:47]

Acknowledged. I discussed this briefly with Hannes as well. We think that this
tried to fix a missing fence between the limit read in line 266 and the
potential limit reset in line 269, but are not sure yet. Anyways, I am not going
to touch it in this CL, to keep this CL a pure refactoring cleanup. But it still
scares me.

     // Avoid blocking GC in long running parser (v8:3974).
-    isolate_->stack_guard()->CheckAndHandleGCInterrupt();
+    isolate_->stack_guard()->HandleGCInterrupt();
   }
 
   if (c0_ == '"') return ParseJsonString();