Simplify current inline allocation tracking mechanism.

Simplify current inline allocation tracking mechanism.

R=yurys@chromium.org

Committed: http://code.google.com/p/v8/source/detail?r=17626

[Michael Starzinger, 2013-11-11 12:27:55]

This just simplifies the current implementation, it does not yet alleviate the
problem of recompiling all code the uses MacroAssembler::Allocate macros.

The number of calls into the runtime should be the same, just the allocation
itself is now also done in the runtime. This addresses several issues I see with
the previous implementation:

- If inlined allocation fails, two events have been emitted.
- In optimized code we now correctly use deferred code.
- All existing code-paths are already thoroughly tested.

This CL should not change tracking semantics, let me know if I missed something.

[yurys, 2013-11-11 12:35:15]

lgtm

[yurys, 2013-11-11 12:38:50]

I assume that this won't trigger GC on each allocation when allocation tracking
is enabled and that the object will be allocated in the same space as it would
have been with inline allocation. We could address the latter in the runtime by
replicating inline logic there when tracking is on but we shouldn't cause extra
GCs.

[Michael Starzinger, 2013-11-11 12:51:40]

On 2013/11/11 12:38:50, yurys wrote:
> I assume that this won't trigger GC on each allocation when allocation
tracking
> is enabled and that the object will be allocated in the same space as it would
> have been with inline allocation. We could address the latter in the runtime
by
> replicating inline logic there when tracking is on but we shouldn't cause
extra
> GCs.

Yes, this will only trigger a GC if bump-pointer allocation as well as free-list
allocation both fail and the space is not being expanded. Since the bump-pointer
allocation in the runtime is semantically the same as the inlined version in
MacroAssembler::Allocate, I don't see a particular reason why the allocation
would turn out to land on a different page. In short: this should not introduce
extra GCs AFAICT.

I agree that the label "gc_required" is named misleadingly in that regard.

[Michael Starzinger, 2013-11-11 18:01:02]

Committed patchset #1 manually as r17626 (presubmit successful).