fast/js/string-concatenate-outofmemory.html seems to be causing some trouble. There have been reports of it blowing out the VM on OS X, making people's machines very sluggish. The test also times out on Windows under DRT.
When I fixed an integer overflow inside UString, the maximum string size that 32-bit JSCore would allocate went from ~180MB to ~1.2GB. This causes the test to put substantially more pressure on both virtual and physical memory. On a Mac with 4GB of RAM, the test completes in less than one second. I've heard reports of it taking several minutes with ~2GB of RAM.
The test was also changed to repeat the repeated concatentation several times. This was done on the assumption that the large strings would be garbage collected by the time the next large string was allocated. This appears to not be the case. This can lead the memory occupied by the strings to climb to over 2GB in size. I'm not sure what the best solution to this is. It seems insane to allow JavaScript to allocate a single string of 1GB in size. It also seems bad that it takes so long for such a large chunk of memory to be garbage collected. Perhaps a hard-coded maximum string size, although dirty, would be in order? It would also solve the issue that this test will completely *kill* any 64-bit machine on which it runs, as the memory allocations would not fail until either swap space or address space is exhausted.
In the meantime I'll go ahead and disable the test. I do not wish to be the subject of Mitz's wrath.
Test disabled in r25239. Leaving this bug open to track finding a solution to the memory use issues it raises.