diff --git a/mozilla/js/tests/js1_5/Array/regress-157652.js b/mozilla/js/tests/js1_5/Array/regress-157652.js
index 1d4a0055cb2..898111c8633 100644
--- a/mozilla/js/tests/js1_5/Array/regress-157652.js
+++ b/mozilla/js/tests/js1_5/Array/regress-157652.js
@@ -45,13 +45,12 @@
 * Note the UBound for uint32's is 2^32 -1 = 0xFFFFFFFF = 4,294,967,295.
 *
 * Check:
+*              js> var arr = new Array(0xFFFFFFFF)
+*              js> arr.length
+*              4294967295
 *
-*   js> var arr = new Array(0xFFFFFFFF)
-*   js> arr.length
-*   4294967295
-*
-*   js> var arr = new Array(0x100000000)
-*   RangeError: invalid array length
+*              js> var arr = new Array(0x100000000)
+*              RangeError: invalid array length
 *
 *
 * We'll try the largest possible array first, then a couple others.
@@ -59,6 +58,56 @@
 *
 * Try to be good about memory by nulling each array variable after it is
 * used. This will tell the garbage collector the memory is no longer needed.
+*
+* As of 2002-08-13, the JS shell runs out of memory no matter what we do,
+* when trying to sort such large arrays.
+*
+* We only want to test that we don't CRASH on the sort. So it will be OK
+* if we get the JS "out of memory" error. Note this terminates the test
+* with exit code 1 in Rhino and exit code 3 in SpiderMonkey. Therefore we put
+*
+*                 |expectExitCode(n = 1,3)|
+*
+* The only problem will arise if the JS shell ever DOES have enough memory
+* to do the sort. Then this test will terminate with the normal exit code 0
+* and fail.
+*
+* Right now, I can't see any other way to do this, because "out of memory"
+* is not a catchable error: it cannot be trapped with try...catch.
+*
+*
+* FURTHER HEADACHE: Rhino can't seem to handle the largest array: it hangs.
+* So we skip this case in Rhino. Here is correspondence with Igor Bukanov.
+* He explains that Rhino isn't actually hanging; it's doing the huge sort:
+*
+* Philip Schwartau wrote:
+*
+* > Hi,
+* >
+* > I'm getting a graceful OOM message on trying to sort certain large
+* > arrays. But if the array is too big, Rhino simply hangs. Note that ECMA
+* > allows array lengths to be anything less than Math.pow(2,32), so the
+* > arrays I'm sorting are legal.
+* >
+* > Note below, I'm getting an instantaneous OOM error on arr.sort() for LEN
+* > = Math.pow(2, 30). So shouldn't I also get one for every LEN between
+* > that and Math.pow(2, 32)? For some reason, I start to hang with 100% CPU
+* > as LEN hits, say, Math.pow(2, 31) and higher. SpiderMonkey gives OOM
+* > messages for all of these. Should I file a bug on this?
+*
+* Igor Bukanov wrote:
+*
+* This is due to different sorting algorithm Rhino uses when sorting
+* arrays with length > Integer.MAX_VALUE. If length can fit Java int,
+* Rhino first copies internal spare array to a temporary buffer, and then
+* sorts it, otherwise it sorts array directly. In case of very spare
+* arrays, that Array(big_number) generates, it is rather inefficient and
+* generates OutOfMemory if length fits int. It may be worth in your case
+* to optimize sorting to take into account array spareness, but then it
+* would be a good idea to file a bug about ineficient sorting of spare
+* arrays both in case of Rhino and SpiderMonkey as SM always uses a
+* temporary buffer.
+*
 */
 //-----------------------------------------------------------------------------
 var bug = 157652;
@@ -67,25 +116,6 @@ var summary = "Testing that Array.sort() doesn't crash on very large arrays";
 printBugNumber(bug);
 printStatus(summary);
 
-/*
- * As of 2002-08-13, the JS shell runs out of memory
- * when trying to sort such large arrays.
- *
- * We only want to test that we don't CRASH on the sort.
- * We'll be happy if we get the JS "out of memory" error.
- * Note this terminates the test with exit code 1 in Rhino
- * and exit code 3 in SpiderMonkey.
- *
- * Therefore we put |expectExitCode(n = 1,3)| below.
- *
- * The only problem will arise if the JS shell ever DOES
- * have enough memory to do the sort. Then this test will
- * terminate with the normal exit code 0 and fail.
- *
- * Right now, I can't see any other way to do this, because
- * "out of memory" is not a catchable error: it cannot be
- * trapped with try...catch.
- */
 var IN_RHINO = inRhino();
 
 if (IN_RHINO)
@@ -93,11 +123,6 @@ if (IN_RHINO)
 else
   expectExitCode(3);
 
-
-/*
- * Rhino can't seem to handle the largest array: it hangs...
- * So we'll skip this case in Rhino -
- */
 if (!IN_RHINO)
 {
   var a1=Array(0xFFFFFFFF);