1/* ***** BEGIN LICENSE BLOCK *****
2* Version: NPL 1.1/GPL 2.0/LGPL 2.1
3*
4* The contents of this file are subject to the Netscape Public License
5* Version 1.1 (the "License"); you may not use this file except in
6* compliance with the License. You may obtain a copy of the License at
7* http://www.mozilla.org/NPL/
8*
9* Software distributed under the License is distributed on an "AS IS" basis,
10* WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
11* for the specific language governing rights and limitations under the
12* License.
13*
14* The Original Code is JavaScript Engine testing utilities.
15*
16* The Initial Developer of the Original Code is Netscape Communications Corp.
17* Portions created by the Initial Developer are Copyright (C) 2002
18* the Initial Developer. All Rights Reserved.
19*
20* Contributor(s): zen-parse@gmx.net, pschwartau@netscape.com
21*
22* Alternatively, the contents of this file may be used under the terms of
23* either the GNU General Public License Version 2 or later (the "GPL"), or
24* the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
25* in which case the provisions of the GPL or the LGPL are applicable instead
26* of those above. If you wish to allow use of your version of this file only
27* under the terms of either the GPL or the LGPL, and not to allow others to
28* use your version of this file under the terms of the NPL, indicate your
29* decision by deleting the provisions above and replace them with the notice
30* and other provisions required by the GPL or the LGPL. If you do not delete
31* the provisions above, a recipient may use your version of this file under
32* the terms of any one of the NPL, the GPL or the LGPL.
33*
34* ***** END LICENSE BLOCK *****
35*
36*
37* Date:    16 July 2002
38* SUMMARY: Testing that Array.sort() doesn't crash on very large arrays
39* See http://bugzilla.mozilla.org/show_bug.cgi?id=157652
40*
41* How large can a JavaScript array be?
42* ECMA-262 Ed.3 Final, Section 15.4.2.2 : new Array(len)
43*
44* This states that |len| must be a a uint32 (unsigned 32-bit integer).
45* Note the UBound for uint32's is 2^32 -1 = 0xFFFFFFFF = 4,294,967,295.
46*
47* Check:
48*              js> var arr = new Array(0xFFFFFFFF)
49*              js> arr.length
50*              4294967295
51*
52*              js> var arr = new Array(0x100000000)
53*              RangeError: invalid array length
54*
55*
56* We'll try the largest possible array first, then a couple others.
57* We're just testing that we don't crash on Array.sort().
58*
59* Try to be good about memory by nulling each array variable after it is
60* used. This will tell the garbage collector the memory is no longer needed.
61*
62* As of 2002-08-13, the JS shell runs out of memory no matter what we do,
63* when trying to sort such large arrays.
64*
65* We only want to test that we don't CRASH on the sort. So it will be OK
66* if we get the JS "out of memory" error. Note this terminates the test
67* with exit code 3. Therefore we put
68*
69*                       |expectExitCode(3);|
70*
71* The only problem will arise if the JS shell ever DOES have enough memory
72* to do the sort. Then this test will terminate with the normal exit code 0
73* and fail.
74*
75* Right now, I can't see any other way to do this, because "out of memory"
76* is not a catchable error: it cannot be trapped with try...catch.
77*
78*
79* FURTHER HEADACHE: Rhino can't seem to handle the largest array: it hangs.
80* So we skip this case in Rhino. Here is correspondence with Igor Bukanov.
81* He explains that Rhino isn't actually hanging; it's doing the huge sort:
82*
83* Philip Schwartau wrote:
84*
85* > Hi,
86* >
87* > I'm getting a graceful OOM message on trying to sort certain large
88* > arrays. But if the array is too big, Rhino simply hangs. Note that ECMA
89* > allows array lengths to be anything less than Math.pow(2,32), so the
90* > arrays I'm sorting are legal.
91* >
92* > Note below, I'm getting an instantaneous OOM error on arr.sort() for LEN
93* > = Math.pow(2, 30). So shouldn't I also get one for every LEN between
94* > that and Math.pow(2, 32)? For some reason, I start to hang with 100% CPU
95* > as LEN hits, say, Math.pow(2, 31) and higher. SpiderMonkey gives OOM
96* > messages for all of these. Should I file a bug on this?
97*
98* Igor Bukanov wrote:
99*
100* This is due to different sorting algorithm Rhino uses when sorting
101* arrays with length > Integer.MAX_VALUE. If length can fit Java int,
102* Rhino first copies internal spare array to a temporary buffer, and then
103* sorts it, otherwise it sorts array directly. In case of very spare
104* arrays, that Array(big_number) generates, it is rather inefficient and
105* generates OutOfMemory if length fits int. It may be worth in your case
106* to optimize sorting to take into account array spareness, but then it
107* would be a good idea to file a bug about ineficient sorting of spare
108* arrays both in case of Rhino and SpiderMonkey as SM always uses a
109* temporary buffer.
110*
111*/
112//-----------------------------------------------------------------------------
113var bug = 157652;
114var summary = "Testing that Array.sort() doesn't crash on very large arrays";
115
116printBugNumber(bug);
117printStatus(summary);
118
119// JSC doesn't run out of memory, so we don't expect an abnormal exit code
120//expectExitCode(3);
121var IN_RHINO = inRhino();
122
123if (!IN_RHINO)
124{
125  var a1=Array(0xFFFFFFFF);
126  a1.sort();
127  a1 = null;
128}
129
130var a2 = Array(0x40000000);
131a2.sort();
132a2=null;
133
134var a3=Array(0x10000000/4);
135a3.sort();
136a3=null;
137