481072 - winmo heap_stress failing

Status: VERIFIED INVALID

(Tamarin Graveyard :: Garbage Collection (mmGC), defect, P2)

Description

[Tommy Reilly]

heap_stress test failing

Comment 1

[Brent Baker]

This testcase is also randomly failing on mac 10.4 intel and ppc, and also will randomly pass on windows mobile. This test is going to be disabled for Windows Mobile and Mac until it is proven to be reliable.


pushed as 1618:715cf9b48a63

Comment 2

[Brent Baker]

Not fixed:

http://hg.mozilla.org/tamarin-redux/rev/715cf9b48a63
was to disable the testcase

Comment 3

[Dan Schaffer]

I can investigate as part of testing oom.  It should run in a reasonable amount of time and stress mmgc without allocating too much memory to fail.  maybe we special case winmo using conditional compilation.

Comment 4

[Lars T Hansen]

Note, could be stack overflow that's poorly detected / poorly handled, which would be important to know.

You do not want to rewrite this but creating a winmo-specific version is probably good.  (We need more heap stress tests anyhow.)

Comment 5

[Lars T Hansen]

Random facts and analysis:

When the benchmark succeeds, it takes about 311 seconds on an HTC Fuze with current (2009-06-29) code, using the JIT.  This is well below the 1000 second timeout that the winmo shell runner places on the process.

I have not yet measured memory consumption, but peak live is at least 12MB assuming very good representations; for our memory representations peak live is probably significantly higher than that.

I have yet to observe the program to fail but I've run it with the standard settings just once so far (many times with smaller settings).

"Random" looking stack overflow is /not/ likely the problem:

WinMo processes receive 58KB stack always.

The avmshell provides 0xf000 - 0x8000 = 28KB for the AS3 stack.  (Observed by measurement on the device.)  Clearly this is not a lot, but it is enough:

The benchmark goes 20 calls deep, all told.

On WinMo, with Visual C++, the frames are rather large in the interpreter at least (640 bytes for the frame plus memory for alloca, easily a couple hundred bytes due to the jmp_buf in the exception frame).  Conservatively, 1KB per frame.  So that's 20KB.  For the JIT I don't know yet.

The GC might go another 20-30 calls deep for its recursive marker, those frames are maybe 200 bytes each, say, so not nearly enough to exhaust 58KB stack.

A stack overflow would in any case not explain the Mac-10.4 and PPC problems; but they could be other bugs, for example, Mac-10.4 does not use virtual memory allocation (due to bugs on that version I believe) and the PPC problems could also be JIT issues or GC corner cases in stack scanning, for example.

(Will run it a few more times to see if it starts to fail.)

Comment 6

[Lars T Hansen]

Three more runs completed OK, same data set, JIT, same execution time.

Brent / Dan / Trevor, I'm thinking that we should just reenable this test to see if it starts failing, if the 5-minute execution time doesn't slow down the build/test process too much.  (If it does I have an 80-second configuration we can use on WinMo.)

Comment 7

[Brent Baker]

I am running a sandbox build with the mmgc/heap_stress test enabled on all platforms. If the run is clean I will then push the change into tamarin-redux

Comment 8

[Lars T Hansen]

Turned out the failures were seen on the Dell Axim, which runs WinMo 5 - which we do not support.  On WinMo 6.5, the test always works.

The test case has also been moved, it is now test/performance/mmgc/gcbench.as, and it should not (yet) be enabled for regular performance runs.