crbug.com/700928  and  crbug.com/738925  are memory bugs caused by aggressive ASLR in v8 triggering the allocation of lots of page tables which OSX never frees.

 crbug.com/870054  is a memory and hang bug caused by worker threads allocating temporary CodeRange objects with random reservation addresses that then cause Windows to allocate and never free CFG memory.

When the OSX bugs were found and fixed we missed an opportunity to find and fix the Windows bug. If we had found it at the time (not a given, by any means, since we wouldn't have known exactly what we were looking for) we could have fixed it much earlier, perhaps in a unified way.

We should learn from this and run some tests on all platforms to make sure that we aren't triggering any other platform "leaks".

I have done manual testing on Windows which suggests that temporary allocations of non-executable memory do not cause any permanent loss of memory - no CFG memory, no page tables, nothing.

However we should consider testing this on Linux and Android and other platforms as well, to see if they have ASLR memory wastage issues.


Alternately/as well we should have a test which attempts to trigger all of the ASLR facilities in v8 - allocate lots of temporary CodeRange objects, allocate and free lots of JavaScript heap objects - and then measure the memory footprint at the end to ensure that it is not higher than it should be. I don't know how to trigger all of these but I assume there should be some way.

We should also consider whether the Windows fix means that we no longer need the OSX fix. The Windows fix (reusing CodeRange reservation addresses) has the advantage of using less CFG/page-table memory in most cases (assuming that just a few CodeRange objects are ever allocated simultaneously) while also not imposing any arbitrary restrictions on how many CodeRange objects are permitted to be allocated simultaneously.