https://codereview.chromium.org/11566011/diff/11001/src/deoptimizer.cc
File src/deoptimizer.cc (right):

https://codereview.chromium.org/11566011/diff/11001/src/deoptimizer.cc#newcode77
src/deoptimizer.cc:77: delete eager_deoptimization_entry_code_;
I don't know what you mean by "trunk". The more I think about this, you
shouldn't be using a VirtualMemory to store this at all. If you need to
need to store the base and size, then store those explicitly rather than
wrapping them in a VirtualMemory object. You don't actually manage the
deopt table's VirtualMemory, so you shouldn't act like you do.

On 2012/12/28 15:04:54, haitao.feng wrote:
When a trunk is returned, the trunk will take control of
eager_deoptimization_entry_code_ and lazy_deoptimization_entry_code_.
The
address in eager_deoptimization_entry_code_ and
lazy_deoptimization_entry_code_
will be NULL.

https://codereview.chromium.org/11566011/diff/11001/src/platform.h
File src/platform.h (right):

https://codereview.chromium.org/11566011/diff/11001/src/platform.h#newcode387
src/platform.h:387: void Set(void* address, size_t size) {
You don't need a struct, just store the base and size. This tuple of
information in _not_ a VirtualMemory object! VirtualMemory objects
_always_ call ReleaseRegion on their address() on destruction if
address() is not zero... and that will happen in your case. Please,
please don't abuse VirtualMemory, which is meant to reserve and manage a
range of virtual addresses, for something it is not.

On 2012/12/28 15:04:54, haitao.feng wrote:
I am using this to get a virtual memory from code range. Otherwise I
need to
create a struct to record the reserved address and size.

https://codereview.chromium.org/11566011/diff/11001/src/spaces.cc
File src/spaces.cc (right):

https://codereview.chromium.org/11566011/diff/11001/src/spaces.cc#newcode361
src/spaces.cc:361: reservation.Set(static_cast<void*>(base), reserved);
See previous comments. Please, please don't abuse the VirtualMemory
object as something it is not.

On 2012/12/28 15:04:54, haitao.feng wrote:
For the double-management, when the memory chunk is created, I reset
the virtual
memory if it is in the code range. The
eager_deoptimization_entry_code_ and
lazy_deoptimization_entry_code_ are reset there.

https://codereview.chromium.org/11566011/

--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev

Reply via email to