On Thu, Apr 28, 2016 at 8:48 AM, Nicholas Nethercote <[email protected] > wrote:
> For the GCs that's because a GC crash often is > triggered by a buggy code (be it in the GC itself, or elsewhere) that > ran substantially earlier. > That's also true for JIT code btw - I've looked at a lot of minidumps and a significant portion of them indicate memory corruption somewhere else (corrupt JIT code or related data structures, or we crash when JIT code accesses GC things and other VM data structures). Having only a few signatures for all of our JIT crashes conflates a lot of different issues (imagine what would happen if most graphics or DOM crashes had the same signature). Hopefully bug 1268029 will help a bit there. I'm not sure what to do about other code corrupting our memory. For example, bug 1124397 is a topcrash (mostly on Mac) in our MacroAssembler. With crash diagnostics I've verified that a number of pages in our buffer (it uses a simple Vector) get poisoned with 0xe5 bytes (jemalloc poison pattern). I think another thread has a use-after-free and poisons our buffer, but it's hard to track this down. How feasible would it be to give (part of) SpiderMonkey its own malloc heap? There are heap fragmentation and memory use concerns, but we could use this only on Nightly or only on 64 bit... Jan _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
