Revert "Imported WebKit commit 0dc6cd75e1d4836eaffbb520be96fac4847cc9d2 (http://svn.webkit.org/repository/webkit/trunk@131300)"

This reverts commit 5466563f4b5b6b86523e3f89bb7f77e5b5270c78.

Caused OOM issues on some CI machines :(

1 files changed, 4 insertions, 4 deletions

diff --git a/Source/JavaScriptCore/runtime/JSLock.cpp b/Source/JavaScriptCore/runtime/JSLock.cpp
index 85dbdfedb..9f02b69b8 100644
--- a/Source/JavaScriptCore/runtime/JSLock.cpp
+++ b/Source/JavaScriptCore/runtime/JSLock.cpp
@@ -140,13 +140,13 @@ bool JSLock::currentThreadIsHoldingLock()
 // context if the thread leaves JSC by making a call out to an external
 // function through a callback.
 //
-// All threads using the context share the same JS stack (the JSStack).
-// Whenever a thread calls into JSC it starts using the JSStack from the
+// All threads using the context share the same JS stack (the RegisterFile).
+// Whenever a thread calls into JSC it starts using the RegisterFile from the
 // previous 'high water mark' - the maximum point the stack has ever grown to
-// (returned by JSStack::end()).  So if a first thread calls out to a
+// (returned by RegisterFile::end()).  So if a first thread calls out to a
 // callback, and a second thread enters JSC, then also exits by calling out
 // to a callback, we can be left with stackframes from both threads in the
-// JSStack.  As such, a problem may occur should the first thread's
+// RegisterFile.  As such, a problem may occur should the first thread's
 // callback complete first, and attempt to return to JSC.  Were we to allow
 // this to happen, and were its stack to grow further, then it may potentially
 // write over the second thread's call frames.