On Octane-raytrace, I see a ton of time under madvise on OS X, 32-bit. I think most of these are coming from shrinkAllocableSpace -> updateDecommittedRegion -> MarkPagesUnused (probably means we keep growing and shrinking the nursery). Commenting out the MarkPagesUnused call in Nursery::updateDecommittedRegion wins at least 25% on Octane-raytrace, so fixing this could be a pretty big win. (Win may be different on Linux/Windows as it depends on the madvise/VirtualProtect implementation.)

(In reply to Jan de Mooij [:jandem] from comment #0) > (Win may be different on Linux/Windows as it depends on the > madvise/VirtualProtect implementation.) Er, VirtualAlloc.

IIRC, madvise is absurdly slow on OSX in particular.

Requesting needinfo to make sure this doesn't slip through the cracks. Relatively low-hanging perf fruit, at least on OS X, and it may affect other benchmarks/websites even more than raytrace.

Andrew is correct, this only shows up on MacOS, where memory management is painfully slow. I was hoping to fix this by landing 988053, but that's going to take cycles I don't have at the moment. I think until I get to that it would be fine to wrap this in #ifndef XP_MACOSX.

Comment on attachment 8404112 [details] [diff] [review] disable_shrink_on_macos-v0.diff Review of attachment 8404112 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/gc/Nursery.h @@ +215,5 @@ > uintptr_t decommitStart = chunk(numActiveChunks_).start(); > JS_ASSERT(decommitStart == AlignBytes(decommitStart, 1 << 20)); > + // Bug 994054: madvise on MacOS is too slow to make this > + // optimization worthwhile. > +# ifndef XP_MACOSX This will cause "unused variable: decommitStart" warnings in OS X opt builds; so move the |uintptr_t decommitStart = ..;| line also inside the #ifndef, or something similar.