On Thu, Feb 27, 2014 at 8:02 PM, Bill McCloskey <[email protected]>wrote:
> I remember that in JaegerMonkey we had code to mark JIT pages > non-writable. I don't think we ever enabled it in release builds because it > was pretty expensive. Should we consider write protection for nightly and > aurora just to see if we can track down this sort of memory corruption? > > I don't know how hard this would be. I remember that the main difficulty > in JM was with ICs. However, don't we already do some memory protection of > JIT pages for the operation callback? Could we reuse some of that code? > Yes that may be a good idea. We could use ExecutableAllocator::toggleAllCodeAsAccessible for this. JIT code is patched intentionally when we add new IC stubs, toggle incremental GC barriers, invalidate Ion code etc, we'd have to make sure all that still works. Maybe with some kind of AutoUnlockJitCode class. I don't know how much this would hurt performance though; ideally we'd only unlock a single page when we patch IC stubs. Jan _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
