-/* ***** BEGIN LICENSE BLOCK *****\r
- * Version: MPL 1.1/GPL 2.0/LGPL 2.1\r
- *\r
- * The contents of this file are subject to the Mozilla Public License Version\r
- * 1.1 (the "License"); you may not use this file except in compliance with\r
- * the License. You may obtain a copy of the License at\r
- * http://www.mozilla.org/MPL/\r
- *\r
- * Software distributed under the License is distributed on an "AS IS" basis,\r
- * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License\r
- * for the specific language governing rights and limitations under the\r
- * License.\r
- *\r
- * The Original Code is JavaScript Engine testing utilities.\r
- *\r
- * The Initial Developer of the Original Code is\r
- * Netscape Communications Corp.\r
- * Portions created by the Initial Developer are Copyright (C) 2002\r
- * the Initial Developer. All Rights Reserved.\r
- *\r
- * Contributor(s):\r
- * zen-parse@gmx.net, pschwartau@netscape.com\r
- *\r
- * Alternatively, the contents of this file may be used under the terms of\r
- * either the GNU General Public License Version 2 or later (the "GPL"), or\r
- * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),\r
- * in which case the provisions of the GPL or the LGPL are applicable instead\r
- * of those above. If you wish to allow use of your version of this file only\r
- * under the terms of either the GPL or the LGPL, and not to allow others to\r
- * use your version of this file under the terms of the MPL, indicate your\r
- * decision by deleting the provisions above and replace them with the notice\r
- * and other provisions required by the GPL or the LGPL. If you do not delete\r
- * the provisions above, a recipient may use your version of this file under\r
- * the terms of any one of the MPL, the GPL or the LGPL.\r
- *\r
- * ***** END LICENSE BLOCK *****\r
- *\r
- *\r
- * Date: 16 July 2002\r
- * SUMMARY: Testing that Array.sort() doesn't crash on very large arrays\r
- * See http://bugzilla.mozilla.org/show_bug.cgi?id=157652\r
- *\r
- * How large can a JavaScript array be?\r
- * ECMA-262 Ed.3 Final, Section 15.4.2.2 : new Array(len)\r
- *\r
- * This states that |len| must be a a uint32 (unsigned 32-bit integer).\r
- * Note the UBound for uint32's is 2^32 -1 = 0xFFFFFFFF = 4,294,967,295.\r
- *\r
- * Check:\r
- * js> var arr = new Array(0xFFFFFFFF)\r
- * js> arr.length\r
- * 4294967295\r
- *\r
- * js> var arr = new Array(0x100000000)\r
- * RangeError: invalid array length\r
- *\r
- *\r
- * We'll try the largest possible array first, then a couple others.\r
- * We're just testing that we don't crash on Array.sort().\r
- *\r
- * Try to be good about memory by nulling each array variable after it is\r
- * used. This will tell the garbage collector the memory is no longer needed.\r
- *\r
- * As of 2002-08-13, the JS shell runs out of memory no matter what we do,\r
- * when trying to sort such large arrays.\r
- *\r
- * We only want to test that we don't CRASH on the sort. So it will be OK\r
- * if we get the JS "out of memory" error. Note this terminates the test\r
- * with exit code 3. Therefore we put\r
- *\r
- * |expectExitCode(3);|\r
- *\r
- * The only problem will arise if the JS shell ever DOES have enough memory\r
- * to do the sort. Then this test will terminate with the normal exit code 0\r
- * and fail.\r
- *\r
- * Right now, I can't see any other way to do this, because "out of memory"\r
- * is not a catchable error: it cannot be trapped with try...catch.\r
- *\r
- *\r
- * FURTHER HEADACHE: Rhino can't seem to handle the largest array: it hangs.\r
- * So we skip this case in Rhino. Here is correspondence with Igor Bukanov.\r
- * He explains that Rhino isn't actually hanging; it's doing the huge sort:\r
- *\r
- * Philip Schwartau wrote:\r
- *\r
- * > Hi,\r
- * >\r
- * > I'm getting a graceful OOM message on trying to sort certain large\r
- * > arrays. But if the array is too big, Rhino simply hangs. Note that ECMA\r
- * > allows array lengths to be anything less than Math.pow(2,32), so the\r
- * > arrays I'm sorting are legal.\r
- * >\r
- * > Note below, I'm getting an instantaneous OOM error on arr.sort() for LEN\r
- * > = Math.pow(2, 30). So shouldn't I also get one for every LEN between\r
- * > that and Math.pow(2, 32)? For some reason, I start to hang with 100% CPU\r
- * > as LEN hits, say, Math.pow(2, 31) and higher. SpiderMonkey gives OOM\r
- * > messages for all of these. Should I file a bug on this?\r
- *\r
- * Igor Bukanov wrote:\r
- *\r
- * This is due to different sorting algorithm Rhino uses when sorting\r
- * arrays with length > Integer.MAX_VALUE. If length can fit Java int,\r
- * Rhino first copies internal spare array to a temporary buffer, and then\r
- * sorts it, otherwise it sorts array directly. In case of very spare\r
- * arrays, that Array(big_number) generates, it is rather inefficient and\r
- * generates OutOfMemory if length fits int. It may be worth in your case\r
- * to optimize sorting to take into account array spareness, but then it\r
- * would be a good idea to file a bug about ineficient sorting of spare\r
- * arrays both in case of Rhino and SpiderMonkey as SM always uses a\r
- * temporary buffer.\r
- *\r
- */\r
-//-----------------------------------------------------------------------------\r
-var bug = 157652;\r
-var summary = "Testing that Array.sort() doesn't crash on very large arrays";\r
-\r
-printBugNumber(bug);\r
-printStatus(summary);\r
-\r
-expectExitCode(3);\r
-var IN_RHINO = inRhino();\r
-\r
-if (!IN_RHINO)\r
-{\r
- var a1=Array(0xFFFFFFFF);\r
- a1.sort();\r
- a1 = null;\r
-}\r
-\r
-var a2 = Array(0x40000000);\r
-a2.sort();\r
-a2=null;\r
-\r
-var a3=Array(0x10000000/4);\r
-a3.sort();\r
-a3=null;\r
+/* ***** BEGIN LICENSE BLOCK *****
+ * Version: MPL 1.1/GPL 2.0/LGPL 2.1
+ *
+ * The contents of this file are subject to the Mozilla Public License Version
+ * 1.1 (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ * http://www.mozilla.org/MPL/
+ *
+ * Software distributed under the License is distributed on an "AS IS" basis,
+ * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
+ * for the specific language governing rights and limitations under the
+ * License.
+ *
+ * The Original Code is JavaScript Engine testing utilities.
+ *
+ * The Initial Developer of the Original Code is
+ * Netscape Communications Corp.
+ * Portions created by the Initial Developer are Copyright (C) 2002
+ * the Initial Developer. All Rights Reserved.
+ *
+ * Contributor(s):
+ * zen-parse@gmx.net, pschwartau@netscape.com
+ *
+ * Alternatively, the contents of this file may be used under the terms of
+ * either the GNU General Public License Version 2 or later (the "GPL"), or
+ * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
+ * in which case the provisions of the GPL or the LGPL are applicable instead
+ * of those above. If you wish to allow use of your version of this file only
+ * under the terms of either the GPL or the LGPL, and not to allow others to
+ * use your version of this file under the terms of the MPL, indicate your
+ * decision by deleting the provisions above and replace them with the notice
+ * and other provisions required by the GPL or the LGPL. If you do not delete
+ * the provisions above, a recipient may use your version of this file under
+ * the terms of any one of the MPL, the GPL or the LGPL.
+ *
+ * ***** END LICENSE BLOCK *****
+ *
+ *
+ * Date: 16 July 2002
+ * SUMMARY: Testing that Array.sort() doesn't crash on very large arrays
+ * See http://bugzilla.mozilla.org/show_bug.cgi?id=157652
+ *
+ * How large can a JavaScript array be?
+ * ECMA-262 Ed.3 Final, Section 15.4.2.2 : new Array(len)
+ *
+ * This states that |len| must be a a uint32 (unsigned 32-bit integer).
+ * 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(0x100000000)
+ * RangeError: invalid array length
+ *
+ *
+ * We'll try the largest possible array first, then a couple others.
+ * We're just testing that we don't crash on Array.sort().
+ *
+ * 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 3. Therefore we put
+ *
+ * |expectExitCode(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;
+var summary = "Testing that Array.sort() doesn't crash on very large arrays";
+
+printBugNumber(bug);
+printStatus(summary);
+
+expectExitCode(3);
+var IN_RHINO = inRhino();
+
+if (!IN_RHINO)
+{
+ var a1=Array(0xFFFFFFFF);
+ a1.sort();
+ a1 = null;
+}
+
+var a2 = Array(0x40000000);
+a2.sort();
+a2=null;
+
+var a3=Array(0x10000000/4);
+a3.sort();
+a3=null;
projects / mono.git / blobdiff