diff --git a/source/core/map-reduce-concurrency.txt b/source/core/map-reduce-concurrency.txt
index 25b381ac1ae..909e8a8b637 100644
--- a/source/core/map-reduce-concurrency.txt
+++ b/source/core/map-reduce-concurrency.txt
@@ -30,12 +30,6 @@ During the operation, map-reduce takes the following locks:
   lock is *global*, and blocks all operations on the :program:`mongod`
   instance.
 
-.. versionchanged:: 2.4
-   The V8 JavaScript engine, which became the default in 2.4, allows
-   multiple JavaScript operations to execute at the same time. Prior to
-   2.4, JavaScript code (i.e. ``map``, ``reduce``, ``finalize``
-   functions) executed in a single thread.
-
 .. note::
    The final write lock during post-processing makes the results appear
    atomically. However, output actions ``merge`` and ``reduce`` may
diff --git a/source/core/server-side-javascript.txt b/source/core/server-side-javascript.txt
index 16508febf86..06a3adaefa1 100644
--- a/source/core/server-side-javascript.txt
+++ b/source/core/server-side-javascript.txt
@@ -59,14 +59,6 @@ Concurrency
    :program:`mongo` shell. For information on this change, see
    :doc:`/release-notes/3.2-javascript`.
 
-.. versionchanged:: 2.4
-
-   The V8 JavaScript engine, which became the default in 2.4, allows
-   multiple JavaScript operations to execute at the same time. Prior to
-   2.4, MongoDB operations that required the JavaScript interpreter had
-   to acquire a lock, and a single :program:`mongod` could only run a
-   single JavaScript operation at a time.
-
 Refer to the individual method or operator documentation for any
 concurrency information. See also the :ref:`concurrency table
 <faq-concurrency-operations-locks>`.
diff --git a/source/faq/concurrency.txt b/source/faq/concurrency.txt
index a05ffb2785d..16b75d4fc7e 100644
--- a/source/faq/concurrency.txt
+++ b/source/faq/concurrency.txt
@@ -82,7 +82,7 @@ For MMAPv1
 The MMAPv1 storage engine uses collection-level locking as of the
 3.0 release series, an improvement on earlier versions in which the
 database lock was the finest-grain lock. Third-party storage engines
-may either use collection-level locking or implement their own 
+may either use collection-level locking or implement their own
 finer-grained concurrency control.
 
 For example, if you have six collections in a database using the
@@ -261,15 +261,6 @@ batches and then apply those batches in parallel. Secondaries do not
 allow reads while applying the write operations, and apply write
 operations in the order that they appear in the oplog.
 
-What kind of concurrency does MongoDB provide for JavaScript operations?
-------------------------------------------------------------------------
-
-.. versionchanged:: 2.4
-   The V8 JavaScript engine added in 2.4 allows multiple JavaScript
-   operations to run at the same time. Prior to 2.4, a single
-   :program:`mongod` could only run a *single* JavaScript operation at
-   once.
-
 Does MongoDB support transactions?
 ----------------------------------
 
@@ -344,4 +335,4 @@ Other systems refer to these semantics as *read uncommitted*.
 
 .. versionchanged:: 3.2
 
-   
+
diff --git a/source/includes/admonitions-eval.rst b/source/includes/admonitions-eval.rst
index 3783be4bf87..d2ece5dee62 100644
--- a/source/includes/admonitions-eval.rst
+++ b/source/includes/admonitions-eval.rst
@@ -25,12 +25,3 @@ Access Control
 .. versionchanged:: 2.6
 
 .. include:: /includes/extracts/access-eval-eval.rst
-
-JavaScript Engine
-~~~~~~~~~~~~~~~~~
-
-.. versionchanged:: 2.4
-
-The V8 JavaScript engine, which became the default in 2.4, allows
-multiple JavaScript operations to execute at the same time. Prior to
-2.4, |object| executed in a single thread.