[heap] refactor inline allocation step code

[heap] refactor inline allocation step code

Once I improved byte accounting done for incremental mark in [1], there is some
code duplication that becomes apparent. This commit refactors the duplicated
code into a private method on NewSpace. This also makes it easy to add new
consumers of inline allocation steps in the future.

[1] https://codereview.chromium.org/1274453002/

R=hpayer@chromium.org
BUG=

Committed: https://crrev.com/1c5e511dc20fc7ff5f5b29ab4157a2143a3d1ede
Cr-Commit-Position: refs/heads/master@{#30921}

[Hannes Payer (out of office), 2015-09-21 07:48:11]

lgtm, just nits

https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h
File src/heap/spaces.h (right):

https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h#newcode2742
src/heap/spaces.h:2742: // allocation steps. `top` the address just past the
last byte allocated, i.e.
top is the memory address of the bump pointer at the last inline allocation
step.

https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h#newcode2744
src/heap/spaces.h:2744: // `new_top` is the address where that the next byte is
going be allocated
remove "that"

https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h#newcode2744
src/heap/spaces.h:2744: // `new_top` is the address where that the next byte is
going be allocated
address of the bump pointer

[ofrobots, 2015-09-21 20:32:58]

https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h
File src/heap/spaces.h (right):

https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h#newcode2742
src/heap/spaces.h:2742: // allocation steps. `top` the address just past the
last byte allocated, i.e.
On 2015/09/21 07:48:10, Hannes Payer wrote:
> top is the memory address of the bump pointer at the last inline allocation
> step.

Did you mean: "top is the memory address of the bump pointer at the last inline
allocation"? Having "step" at the end doesn't make sense to me. This was
probably a typo, but I want to make sure we are on the same .... page (heh).

[Hannes Payer (out of office), 2015-09-22 07:50:52]

On 2015/09/21 20:32:58, ofrobots wrote:
> https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h
> File src/heap/spaces.h (right):
> 
>
https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h#newcode2742
> src/heap/spaces.h:2742: // allocation steps. `top` the address just past the
> last byte allocated, i.e.
> On 2015/09/21 07:48:10, Hannes Payer wrote:
> > top is the memory address of the bump pointer at the last inline allocation
> > step.
> 
> Did you mean: "top is the memory address of the bump pointer at the last
inline
> allocation"? Having "step" at the end doesn't make sense to me. This was
> probably a typo, but I want to make sure we are on the same .... page (heh).

Yeah, better without "step" :)

[ofrobots, 2015-09-23 14:53:39]

On 2015/09/22 07:50:52, Hannes Payer wrote:
> On 2015/09/21 20:32:58, ofrobots wrote:
> > https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h
> > File src/heap/spaces.h (right):
> > 
> >
>
https://codereview.chromium.org/1351983002/diff/1/src/heap/spaces.h#newcode2742
> > src/heap/spaces.h:2742: // allocation steps. `top` the address just past the
> > last byte allocated, i.e.
> > On 2015/09/21 07:48:10, Hannes Payer wrote:
> > > top is the memory address of the bump pointer at the last inline
allocation
> > > step.
> > 
> > Did you mean: "top is the memory address of the bump pointer at the last
> inline
> > allocation"? Having "step" at the end doesn't make sense to me. This was
> > probably a typo, but I want to make sure we are on the same .... page (heh).
> 
> Yeah, better without "step" :)

patch-set-2 is a comments only change that addresses the nits found in
patch-set-1.  PTAL.

[Hannes Payer (out of office), 2015-09-24 10:58:08]

one more nit, lgtm, just go ahead and land it.

https://codereview.chromium.org/1351983002/diff/20001/src/heap/spaces.h
File src/heap/spaces.h (right):

https://codereview.chromium.org/1351983002/diff/20001/src/heap/spaces.h#newco...
src/heap/spaces.h:2741: // operation. Right now incremental mark is the only
consumer of inline
marking

[ofrobots, 2015-09-24 17:53:59]

The CQ bit was checked by ofrobots@google.com

[ofrobots, 2015-09-24 17:53:59]

The patchset sent to the CQ was uploaded after l-g-t-m from hpayer@chromium.org
Link to the patchset: https://codereview.chromium.org/1351983002/#ps40001
(title: "fix the additional nit")

[commit-bot: I haz the power, 2015-09-24 17:54:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1351983002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1351983002/40001

[commit-bot: I haz the power, 2015-09-24 18:22:15]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-09-24 18:22:33]

Patchset 3 (id:??) landed as
https://crrev.com/1c5e511dc20fc7ff5f5b29ab4157a2143a3d1ede
Cr-Commit-Position: refs/heads/master@{#30921}