Make unused semispace available to other isolates.

Make unused semispace available to other isolates.

When not scavenging, hand the unused semispace back to the system,
with a one-element cache (to avoid the cost of clearing).

Example memory footprint reduction:
* a short-running single-isolate process that never needs a scavenge: half
* VM service enabled but never used: one semi-space
* N isolates with no more than M scavenging simultaneously: N-M semi-spaces

R=iposva@google.com

Committed: https://code.google.com/p/dart/source/detail?r=37100

[Ivan Posva, 2014-06-05 22:27:29]

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.cc
File runtime/vm/scavenger.cc (right):

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.cc#...
runtime/vm/scavenger.cc:351: if (reserved == NULL ||
!reserved->Commit(VirtualMemory::kReadWrite)) {
(reserved == NULL)

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.cc#...
runtime/vm/scavenger.cc:352: // TODO(koda): If cache_ is not empty, we could try
to delete it.
If Commit failed you probably do not want to leak the virtual address space
associated with the reservation.

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.cc#...
runtime/vm/scavenger.cc:413: from_->Delete();
ASSERT(from_ == NULL)

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h
File runtime/vm/scavenger.h (right):

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h#n...
runtime/vm/scavenger.h:31: public:
Please use vertical space for easier reading.

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h#n...
runtime/vm/scavenger.h:36: // Hand back an unused space. Safe to call on NULL.
Why would we ever want to call Delete on NULL?

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h#n...
runtime/vm/scavenger.h:46: void WriteProtect(bool read_only);
Do we ever write protect a new gen?

[koda, 2014-06-05 23:04:23]

PTAL

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.cc
File runtime/vm/scavenger.cc (right):

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.cc#...
runtime/vm/scavenger.cc:351: if (reserved == NULL ||
!reserved->Commit(VirtualMemory::kReadWrite)) {
On 2014/06/05 22:27:28, Ivan Posva wrote:
> (reserved == NULL)

Done.

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.cc#...
runtime/vm/scavenger.cc:352: // TODO(koda): If cache_ is not empty, we could try
to delete it.
On 2014/06/05 22:27:28, Ivan Posva wrote:
> If Commit failed you probably do not want to leak the virtual address space
> associated with the reservation.

Done.

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.cc#...
runtime/vm/scavenger.cc:413: from_->Delete();
On 2014/06/05 22:27:28, Ivan Posva wrote:
> ASSERT(from_ == NULL)

Done.

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h
File runtime/vm/scavenger.h (right):

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h#n...
runtime/vm/scavenger.h:31: public:
On 2014/06/05 22:27:29, Ivan Posva wrote:
> Please use vertical space for easier reading.

Done.

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h#n...
runtime/vm/scavenger.h:36: // Hand back an unused space. Safe to call on NULL.
On 2014/06/05 22:27:29, Ivan Posva wrote:
> Why would we ever want to call Delete on NULL?

Allowing NULL keeps it consistent with the 'delete' operator, and may save some
if-statements.

But if you prefer, we can disallow it.

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h#n...
runtime/vm/scavenger.h:46: void WriteProtect(bool read_only);
On 2014/06/05 22:27:29, Ivan Posva wrote:
> Do we ever write protect a new gen?

Heap::WriteProtect includes new gen, but it's currently only called for the VM
isolate, whose new gen is empty.

But in any case, I think it makes sense to have VirtualMemory remember its
protection mode.

I'm fine with either:
a) Unprotect the memory in Delete if needed.
b) Only support write-protect on a heap when its new gen is empty.

What do you think?

[koda, 2014-06-05 23:08:29]

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h
File runtime/vm/scavenger.h (right):

https://codereview.chromium.org/320463003/diff/60001/runtime/vm/scavenger.h#n...
runtime/vm/scavenger.h:36: // Hand back an unused space. Safe to call on NULL.
On 2014/06/05 23:04:23, koda wrote:
> On 2014/06/05 22:27:29, Ivan Posva wrote:
> > Why would we ever want to call Delete on NULL?
> 
> Allowing NULL keeps it consistent with the 'delete' operator, and may save
some
> if-statements.
> 
> But if you prefer, we can disallow it.

Actually, the commit failure check in this very CL (scavenger.cc) is an example
of when 'delete' on NULL is convenient.

[Ivan Posva, 2014-06-05 23:39:00]

LGTM -ip

[koda, 2014-06-06 20:20:37]

Committed patchset #7 manually as r37100 (presubmit successful).