The handling of the guard page is at two different levels now. At one level
when
handling allocation and at another level when handling deallocation. We
should
fix that. In particular I don't like that the address you get from
AllocateRawMemory is not the address you should give to FreeRawMemory when
you
want to deallocate it.
http://codereview.chromium.org/7379004/diff/12005/src/platform-cygwin.cc
File src/platform-cygwin.cc (right):
http://codereview.chromium.org/7379004/diff/12005/src/platform-cygwin.cc#newcode170
src/platform-cygwin.cc:170: mprotect(address, size, PROT_NONE);
Instead of having identical code in all of these platform files, please
just add this to platform-posix.cc. That will take care of freebsd,
openbsd, linux, macos, solaris and cygwin.
http://codereview.chromium.org/7379004/diff/12005/src/spaces.cc
File src/spaces.cc (right):
http://codereview.chromium.org/7379004/diff/12005/src/spaces.cc#newcode411
src/spaces.cc:411: OS::Free(static_cast<char*>(mem) - guardsize, length
+ guardsize);
This looks nasty to me. Doesn't this mean that to free executable memory
you have to pass in another address than the one you got from
AllocateRawMemory? We should avoid that.
http://codereview.chromium.org/7379004/diff/12005/src/spaces.cc#newcode2692
src/spaces.cc:2692: if (size < requested) {
Shouldn't you add guardsize to requested before you get here? Otherwise
you might not have enough space for the guard page.
http://codereview.chromium.org/7379004/diff/12005/src/spaces.cc#newcode2694
src/spaces.cc:2694: static_cast<Address>(mem) - guardsize, size +
guardsize, executable);
I'm getting confused here. Does this add up? FreeRawMemory will subtract
guardsize again, right?
http://codereview.chromium.org/7379004/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
