- Add the ability to protect VirtualMemory.

- Add the ability to protect VirtualMemory.
- Write protect the VM isolate once it has been constructed.
Committed: https://code.google.com/p/dart/source/detail?r=9984

[siva, 2012-07-27 01:55:00]

LGTM with some API comments.

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/heap.cc
File runtime/vm/heap.cc (right):

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/heap.cc#new...
runtime/vm/heap.cc:232: code_space_->Protect(mode);
This seems weird here as we independently set the code pages to executable.
If somebody calls heap()->Protect(kReadWrite);
hoping to make the new space and old space non executable they would
inadvertently set the code pages also as non executable.

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:6054: // Hook up predefined classes without setting their
library pointers.
The comment on top seems more meaningful i.e.

// The class 'Dynamic' is registered in the class dictionary because it's name
is a built-in identifier, rather than a reserved keyword. It's name is not heap
allocated, because the class resides in the VM isolate. This class is registered
into the dictionary without setting the corresponding library pointer in the
class as it is in the VM isolate which is read only.

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/pages.cc
File runtime/vm/pages.cc (right):

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/pages.cc#ne...
runtime/vm/pages.cc:358: }
How does this work in the face of heap growth?

i.e we called heap()->Protect(kReadWrite);

how does it then work when we grow the heap.

[Ivan Posva, 2012-07-27 18:02:55]

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/heap.cc
File runtime/vm/heap.cc (right):

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/heap.cc#new...
runtime/vm/heap.cc:232: code_space_->Protect(mode);
On 2012/07/27 01:55:00, asiva wrote:
> This seems weird here as we independently set the code pages to executable.
> If somebody calls heap()->Protect(kReadWrite);
> hoping to make the new space and old space non executable they would
> inadvertently set the code pages also as non executable.

Done.

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/object.cc#n...
runtime/vm/object.cc:6054: // Hook up predefined classes without setting their
library pointers.
On 2012/07/27 01:55:00, asiva wrote:
> The comment on top seems more meaningful i.e.
> 
> // The class 'Dynamic' is registered in the class dictionary because it's name
> is a built-in identifier, rather than a reserved keyword. It's name is not
heap
> allocated, because the class resides in the VM isolate. This class is
registered
> into the dictionary without setting the corresponding library pointer in the
> class as it is in the VM isolate which is read only.

Added a better comment. The name should actually be setup for the shared classes
once we can properly use strings from the VM isolate.

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/pages.cc
File runtime/vm/pages.cc (right):

https://chromiumcodereview.appspot.com/10830045/diff/1/runtime/vm/pages.cc#ne...
runtime/vm/pages.cc:358: }
On 2012/07/27 01:55:00, asiva wrote:
> How does this work in the face of heap growth?
> 
> i.e we called heap()->Protect(kReadWrite);
> 
> how does it then work when we grow the heap.

A read-write heap should be able to grow a read-only heap should be caught at
allocation time.