VM: Inline Scavenger and PageSpace objects into Heap.

VM: Inline Scavenger and PageSpace objects into Heap.

This allows accessing members from generated code via THR with one
indirection less. (e.g. Scavenger::TopAddress, Scavenger::EndAddress)

Currently, these addresses are still inlined into generated code, but for
isolate-shared code those have to loaded indirectly via THR.
It also avoids the extra new/delete for new_space_ and old_space_.

Landed as part of https://codereview.chromium.org/1241863002/.
BUG=

[Florian Schneider, 2015-07-15 13:55:34]

fschneider@google.com changed reviewers:
+ koda@google.com

[koda, 2015-07-15 14:15:09]

Why not move them even closer to THR already? For now, we can cache
Top/EndAddress in Thread (and then eventually we'll probably want actual top/end
fields in there). It will introduce some coupling, and it would be nice to have
a general way to sync select fields with the Thread, but for now you can just
set/clear the cache in Enter/ExitIsolate.

[koda, 2015-07-15 14:36:51]

On 2015/07/15 14:15:09, koda wrote:
> Why not move them even closer to THR already? For now, we can cache
> Top/EndAddress in Thread (and then eventually we'll probably want actual
top/end
> fields in there). It will introduce some coupling, and it would be nice to
have
> a general way to sync select fields with the Thread, but for now you can just
> set/clear the cache in Enter/ExitIsolate.

... and as a general note, we'll probably want to be selective w.r.t. which
fields we put close to THR, to ensure we stay within the 8 bit offset limit to
fit into a single load on 32-bit ARM.

[Florian Schneider, 2015-07-16 08:12:59]

On 2015/07/15 14:15:09, koda wrote:
> Why not move them even closer to THR already? For now, we can cache
> Top/EndAddress in Thread (and then eventually we'll probably want actual
top/end
> fields in there). It will introduce some coupling, and it would be nice to
have
> a general way to sync select fields with the Thread, but for now you can just
> set/clear the cache in Enter/ExitIsolate.

Sure, caching them in Thread is also an option.

But what do you see against landing this CL first? It is both
an improvement and a simplification, isn't it?

[koda, 2015-07-16 13:43:38]

lgtm

Sure, that's fine. (Potential downsides is tighter include deps (thus build
time) and less control over construction/destruction order, but neither of those
are really any problem in this particular case. )

[koda, 2015-07-16 14:09:04]

https://codereview.chromium.org/1235433004/diff/1/runtime/vm/pages.cc
File runtime/vm/pages.cc (right):

https://codereview.chromium.org/1235433004/diff/1/runtime/vm/pages.cc#newcode175
runtime/vm/pages.cc:175: PageSpace::~PageSpace() {
... actually, we should probably move this into a Shutdown method. It's extra
painful to debug deadlocks in automatically invoked destructors.

I can do it.

[Florian Schneider, 2015-07-17 13:16:08]

On 2015/07/16 13:43:38, koda wrote:
> lgtm
> 
> Sure, that's fine. (Potential downsides is tighter include deps (thus build
> time) and less control over construction/destruction order, but neither of
those
> are really any problem in this particular case. )

Thanks. Closing this since I landed it as part of
https://codereview.chromium.org/1241863002/.