487431 - Peak memory used when running performance suite varies drastically between platforms

Status: VERIFIED FIXED

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

Description

[Brent Baker]

You can get the peak memory used running a test from runtests.py by passing the --memory switch:

./runtests.py --config=jsbench --memory

This executes the shell with --memstats and parses the stdio looking for "[mem] private" and tracks the largest value: [test/performance/runtests.py:374-387]

testname [windows, mac, linux]

jsbench/Crypt.as [49.2M, 53.0M, 68.8M]
jsbench/Euler.as [16.3M, 6.6M, 37.2M]
jsbench/FFT.as [42.6M, 39.6M, 87.5M]
jsbench/HeapSort.as [10.1M, 10.9M, 23.8M]
jsbench/LUFact.as [172.8M, 134.7M, 144.2M]
jsbench/Moldyn.as [28.9M, 1.8M, 82.4M]
jsbench/RayTracer.as [13.5M, 1.9M, 32.5M]
jsbench/Series.as [40.0M, 32.1M, 57.3M]
jsbench/SOR.as [66.1M, 61.4M, 93.7M]
jsbench/SparseMatmult.as [27.1M, 15.0M, 59.0M]

Comment 1

[Lars T Hansen]

A more dramatic example is scimark/MonteCarlo, where Win/Mac report that they are using shy of 2MB whereas Linux reports using 80MB.

I booted up my linux vm and built tamarin-redux with MonteCarlo running in the interpreter (some source of noise there, yeah) and cat'ed /proc/#/smaps and summed the Private segments, which is what the code in Tamarin does.  It gives me 45MB, which is about half of what the web page states but still 30x what MacOS reports.  And looking through that dump there are many 1MB segments allocated.  Ergo, it does appear at first blush that the Linux accouting is not out to sea, but that the allocator is wonky.

The MacOS and Windows accounting could be broken, or there could be something else up.

A quick test on MacOS shows that the same test does not grow the 'Real memory' number reported by the activity monitor above 2.7MB (but VM is quite high).

The main problem seems to be that a very large number of collections is run on MacOS (675?) whereas a very small number is run on Linux (5).

Comment 2

[Lars T Hansen]

This is a direct consequence of a bug I've pointed out elsewhere, that GCPolicyManager::interCollectionTicks returns a value that is independent of the tick frequency on the machine.  (1MHz for Linux yields a 1.5s inter-collection lag here; Mac and Windows have much higher frequencies and can collect much more often.)  When setting this to a number of ticks corresponding to 10ms (which is still 6.6 times longer than on MacOS X) the number of collections rises to 494 and the private memory peak drops to 2.6MB.

Comment 3

[Lars T Hansen]

Attachment: Sets interCollectionTicks to a value always corresponding to 15ms

I doubt this fix is perfect but it is an improvement over what we had.  Incidentally this will reduce collection frequency somewhat on Windows and Mac because the old code set it to 1.5ms, that seems very rapid to me and is likely a bug, judging from comments in the code.

Comment 4

[Rishit Shah]

For ARM its 1/64 seconds = 15.625 ms.  The closest rounding would be to 16ms and as a side effect that would possibly make the calculation faster = left shift by 4 instead of multiplication.

Comment 5

[Lars T Hansen]

Point noted.  However, this is a number of ticks and can be far from perfect, it just needs to be in the ballpark of something sane.  Also, if this division is in any way performance critical then we have other issues to contend with.  For the moment I would like to have obvious code, not something too optimized.

Comment 6

[Lars T Hansen]

redux changeset:   1725:8c44c6fa81bc