Move aligned allocation to the platform files.

Move aligned allocation to the platform files.

The Windows platform now don't assume that it can free part of a reservation.
Instead it first allocates a too large block, then frees it and tries to
allocate an aligned part of the block it just freed. It retries if a race
condition allowed someone else in the same procress to allocate the same block.

BUG=v8:1467
Committed: http://code.google.com/p/v8/source/detail?r=9296

[Vyacheslav Egorov (Chromium), 2011-09-12 13:42:48]

http://codereview.chromium.org/7865025/diff/2001/src/platform-win32.cc
File src/platform-win32.cc (right):

http://codereview.chromium.org/7865025/diff/2001/src/platform-win32.cc#newcod...
src/platform-win32.cc:1529: } while (result == NULL);
this looks too fragile and might go into infinite loop. 

lets limit number of retries and fallback to "wasteful" allocation if it fails.
to make "wasteful" allocation work property we need to track the base pointer to
enable correct virtualfree with MEM_RELEASE later (e.g. NewSpace can own base
pointer for deallocation of aligned new space chunk; pages can track base
pointer in the header. etc.).

http://codereview.chromium.org/7865025/diff/2001/src/platform-win32.cc#newcod...
src/platform-win32.cc:1552: return VirtualFree(base, 0, MEM_DECOMMIT) != 0;
Should not it become MEM_RELEASE?

[Lasse Reichstein, 2011-09-12 19:18:02]

http://codereview.chromium.org/7865025/diff/2001/src/platform-win32.cc
File src/platform-win32.cc (right):

http://codereview.chromium.org/7865025/diff/2001/src/platform-win32.cc#newcod...
src/platform-win32.cc:1529: } while (result == NULL);
This was an attempt to avoid finding a place to store that pointer.
The infinite loop is implausible, but I agree, not impossible. I guess this
needs rethinking.

http://codereview.chromium.org/7865025/diff/2001/src/platform-win32.cc#newcod...
src/platform-win32.cc:1552: return VirtualFree(base, 0, MEM_DECOMMIT) != 0;
Absolutely! It should have been that all along! This means we never release
memory. How inconvenient.

[Vyacheslav Egorov (Chromium), 2011-09-14 12:46:51]

lgtm

http://codereview.chromium.org/7865025/diff/6001/src/platform-linux.cc
File src/platform-linux.cc (right):

http://codereview.chromium.org/7865025/diff/6001/src/platform-linux.cc#newcod...
src/platform-linux.cc:137: // Here gcc is telling us that we are on an MIPS and
gcc is assuming that we
Accident edit?

http://codereview.chromium.org/7865025/diff/6001/src/platform-win32.cc
File src/platform-win32.cc (right):

http://codereview.chromium.org/7865025/diff/6001/src/platform-win32.cc#newcode70
src/platform-win32.cc:70: }
Accident edit?

http://codereview.chromium.org/7865025/diff/8001/src/spaces.h
File src/spaces.h (right):

http://codereview.chromium.org/7865025/diff/8001/src/spaces.h#newcode334
src/spaces.h:334: VirtualMemory* reservation() {
reservation is a bit confusing name.

UnderlyingMaping, vmem or something less confusing.

http://codereview.chromium.org/7865025/diff/8001/src/spaces.h#newcode339
src/spaces.h:339: reservation_.Reset();
InitializeReservation

[Lasse Reichstein, 2011-09-15 10:58:49]

http://codereview.chromium.org/7865025/diff/6001/src/platform-linux.cc
File src/platform-linux.cc (right):

http://codereview.chromium.org/7865025/diff/6001/src/platform-linux.cc#newcod...
src/platform-linux.cc:137: // Here gcc is telling us that we are on an MIPS and
gcc is assuming that we
No edit visible to me?

http://codereview.chromium.org/7865025/diff/6001/src/platform-win32.cc
File src/platform-win32.cc (right):

http://codereview.chromium.org/7865025/diff/6001/src/platform-win32.cc#newcode70
src/platform-win32.cc:70: }
Also no edit here.
Are you comparing to previous CL (because an update of the working checkout to
tip of tree will make that not work).