Black allocation during scavenges will push objects on the marking deque that point to to-space. They should not be cleared.

BUG=chromium:561449
LOG=n

Review URL: https://codereview.chromium.org/1683983003

Cr-Commit-Position: refs/heads/master@{#33875}

Mark null and undefined as undetectable, and use it to handle abstract equality comparison in the generic compare ic

Marking as undetectable makes abstract equality of null, undefined, and
other undetectable objects easier. Supporting it in the generic compare
IC significantly speeds up dynamic comparison between those values and
JSReceivers by not falling back to the runtime.

MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>

Review URL: https://codereview.chromium.org/1683643002

Cr-Commit-Position: refs/heads/master@{#33858}

Preparing the young generation for (real) non-contiguous backing memory, this
change removes object masks that are used to compute containment in semi and new
space. The masks are replaced by lookups for object tags and page headers, where
possible.

Details:
- Use the fast checks (page header lookups) for containment in regular code.
- Use the slow version that masks out the page start adress and iterates all
  pages of a space for debugging/verification.
- The slow version works for off-heap/unmapped memory.
- Encapsulate all checks for the old->new barrier in Heap::RecordWrite().

BUG=chromium:581412
LOG=N

Review URL: https://codereview.chromium.org/1632913003

Cr-Commit-Position: refs/heads/master@{#33857}

Instead of only sweeping a specific space, let tasks work together once they have
swept their corresponding space.

BUG=

Review URL: https://codereview.chromium.org/1678863002

Cr-Commit-Position: refs/heads/master@{#33849}

BUG=chromium:578883
LOG=NO

Review URL: https://codereview.chromium.org/1675163003

Cr-Commit-Position: refs/heads/master@{#33841}

This replaces the global remembered set with per-page remembered sets.

Each page in the old space, map space, and large object space keeps track of
the set of slots in the page pointing to the new space.

The data structure for storing slot sets is a two-level bitmap, which allows
us to remove the store buffer overflow and SCAN_ON_SCAVENGE logic.

Design doc: https://goo.gl/sMKCf7

BUG=chromium:578883
LOG=NO

Review URL: https://codereview.chromium.org/1608583002

Cr-Commit-Position: refs/heads/master@{#33806}

It's fine to use JS_OBJECT_TYPE for JSIteratorResult and only have a
preallocated initial map for them to avoid unnecessary polymorphism
from generators / builtin iterators. The instance type doesn't
provide any advantage, since we always have to treat JSIteratorResult
objects as regular JSObjects later.

R=yangguo@chromium.org
TBR=hpayer@chromium.org

Review URL: https://codereview.chromium.org/1680513002

Cr-Commit-Position: refs/heads/master@{#33800}

This makes the dispatch table similar to the builtins code list and makes
sure that the dispatch table does not move.

R=mstarzinger@chromium.org, rmcilroy@chromium.org

Review URL: https://codereview.chromium.org/1671813003

Cr-Commit-Position: refs/heads/master@{#33781}

- remove unused counters
- add "ic" prefix to all ic-counters
- add more counter: maps-created, global deopts (not used yet)

BUG=

Review URL: https://codereview.chromium.org/1553523002

Cr-Commit-Position: refs/heads/master@{#33768}

Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )

Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1670813005

Cr-Commit-Position: refs/heads/master@{#33766}

(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1668103002

Cr-Commit-Position: refs/heads/master@{#33741}

Code compiled during snapshot are overwhelmingly for functions
that are only used for bootstrapping. It makes no sense to
include them in the startup snapshot, which bloats up the snapshot size
and slows down deserialization.

Snapshot sizes for comparison, for ia32:
w/o --ignition:   484k
w/ --ignition:    537k
bytecode removed: 489k

R=rmcilroy@chromium.org,mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1667693002

Cr-Commit-Position: refs/heads/master@{#33734}

BUG=

Review URL: https://codereview.chromium.org/1647123002

Cr-Commit-Position: refs/heads/master@{#33718}

Reland of [heap] Simplify distribution of remaining memory during sweeping & compaction (patchset #1 id:1 of https://codereview.chromium.org/1661723003/ )

Reason for revert:
Bisection results show that this was not the culprit.

Original issue's description:
> Revert of [heap] Simplify distribution of remaining memory during sweeping & compaction (patchset #2 id:80001 of https://codereview.chromium.org/1653973003/ )
>
> Reason for revert:
> Very likely blocking roll: https://codereview.chromium.org/1652413003/
>
> Original issue's description:
> > [heap] Simplify distribution of remaining memory during sweeping & compaction
> >
> > BUG=chromium:524425
> > LOG=N
> >
> > Committed: https://crrev.com/f72923526ccaa8faef5c977267b0c074c4a44dfa
> > Cr-Commit-Position: refs/heads/master@{#33668}
>
> TBR=hpayer@chromium.org,mlippautz@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:524425
>
> Committed: https://crrev.com/a9441b0e7a2a56c2047482a3cc66e3ca2255444b
> Cr-Commit-Position: refs/heads/master@{#33695}

TBR=hpayer@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425

Review URL: https://codereview.chromium.org/1663013002

Cr-Commit-Position: refs/heads/master@{#33696}

Revert of [heap] Simplify distribution of remaining memory during sweeping & compaction (patchset #2 id:80001 of https://codereview.chromium.org/1653973003/ )

Reason for revert:
Very likely blocking roll: https://codereview.chromium.org/1652413003/

Original issue's description:
> [heap] Simplify distribution of remaining memory during sweeping & compaction
>
> BUG=chromium:524425
> LOG=N
>
> Committed: https://crrev.com/f72923526ccaa8faef5c977267b0c074c4a44dfa
> Cr-Commit-Position: refs/heads/master@{#33668}

TBR=hpayer@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425

Review URL: https://codereview.chromium.org/1661723003

Cr-Commit-Position: refs/heads/master@{#33695}

BUG=chromium:524425
LOG=N

Review URL: https://codereview.chromium.org/1653973003

Cr-Commit-Position: refs/heads/master@{#33668}

This function is called for every live object in new space.  We statically know
which version to call, so let's use templates here and eliminite a branch at
runtime.

BUG=chromium:524425
LOG=N

Review URL: https://codereview.chromium.org/1659823002

Cr-Commit-Position: refs/heads/master@{#33662}

String wrappers (new String("foo")) are special objects: their string
characters are accessed like elements, and they also have an elements
backing store. This used to require a bunch of explicit checks like:

if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
  /* Handle string characters */
}
// Handle regular elements (for string wrappers and other objects)
obj->GetElementsAccessor()->Whatever(...);

This CL introduces new ElementsKinds for string wrapper objects (one for
fast elements, one for dictionary elements), which allow folding the
special-casing into new StringWrapperElementsAccessors.

No observable change in behavior is intended.

Review URL: https://codereview.chromium.org/1612323003

Cr-Commit-Position: refs/heads/master@{#33616}

BUG=

Review URL: https://codereview.chromium.org/1649653004

Cr-Commit-Position: refs/heads/master@{#33593}

This change adds AbstractCode, which can be either Code or
BytecodeArray, and adds methods to calculate source position based
on that. Also cleans up to use code offsets instead of raw PC
where possible, and consistently uses the offset from instruction
start (as opposed to code object start).

R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

Review URL: https://codereview.chromium.org/1618343002

Cr-Commit-Position: refs/heads/master@{#33579}

This currently works since we never call set_target_cell when we have to record slots for evacuation. It would break with black allocation.

BUG=chromium:561449
LOG=n

Review URL: https://codereview.chromium.org/1643573003

Cr-Commit-Position: refs/heads/master@{#33575}

Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )

Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1643533003

Cr-Commit-Position: refs/heads/master@{#33556}

This reverts commit 85ba94f2.

All parallelism can be turned off using --predictable, or --noparallel-compaction.

This patch completely parallelizes
 - semispace copy: from space -> to space (within newspace)
 - newspace evacuation: newspace -> oldspace
 - oldspace compaction: oldspace -> oldspace

Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).

Some low-level details:
 - The hard cap on number of tasks has been lifted
 - We cache store buffer entries locally before merging them back into the global
   StoreBuffer in a finalization phase.
 - We cache AllocationSite operations locally before merging them back into the
   global pretenuring storage in a finalization phase.
 - AllocationSite might be compacted while they would be needed for newspace
   evacuation. To mitigate any problems we defer checking allocation sites for
   newspace till merging locally buffered data.

CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org

Review URL: https://codereview.chromium.org/1640563004

Cr-Commit-Position: refs/heads/master@{#33552}

(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1642613002

Cr-Commit-Position: refs/heads/master@{#33548}

Revert of [heap] Parallel newspace evacuation, semispace copy, and compaction \o/ (patchset #16 id:620001 of https://codereview.chromium.org/1577853007/ )

Reason for revert:
[Sheriff] Leads to crashes on all webrtc chromium testers, e.g.:
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/49664

Original issue's description:
> [heap] Parallel newspace evacuation, semispace copy, and compaction \o/
>
> All parallelism can be turned off using --predictable, or --noparallel-compaction.
>
> This patch completely parallelizes
>  - semispace copy: from space -> to space (within newspace)
>  - newspace evacuation: newspace -> oldspace
>  - oldspace compaction: oldspace -> oldspace
>
> Previously newspace has been handled sequentially (semispace copy, newspace
> evacuation) before compacting oldspace in parallel. However, on a high level
> there are no dependencies between those two actions, hence we parallelize them
> altogether. We base the number of evacuation tasks on the overall set of
> to-be-processed pages (newspace + oldspace compaction pages).
>
> Some low-level details:
>  - The hard cap on number of tasks has been lifted
>  - We cache store buffer entries locally before merging them back into the global
>    StoreBuffer in a finalization phase.
>  - We cache AllocationSite operations locally before merging them back into the
>    global pretenuring storage in a finalization phase.
>  - AllocationSite might be compacted while they would be needed for newspace
>    evacuation. To mitigate any problems we defer checking allocation sites for
>    newspace till merging locally buffered data.
>
> CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
> BUG=chromium:524425
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/8f0fd8c0370ae8c5aab56491b879d7e30c329062
> Cr-Commit-Position: refs/heads/master@{#33523}

TBR=hpayer@chromium.org,ulan@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425

Review URL: https://codereview.chromium.org/1643473002

Cr-Commit-Position: refs/heads/master@{#33539}

All parallelism can be turned off using --predictable, or --noparallel-compaction.

This patch completely parallelizes
 - semispace copy: from space -> to space (within newspace)
 - newspace evacuation: newspace -> oldspace
 - oldspace compaction: oldspace -> oldspace

Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).

Some low-level details:
 - The hard cap on number of tasks has been lifted
 - We cache store buffer entries locally before merging them back into the global
   StoreBuffer in a finalization phase.
 - We cache AllocationSite operations locally before merging them back into the
   global pretenuring storage in a finalization phase.
 - AllocationSite might be compacted while they would be needed for newspace
   evacuation. To mitigate any problems we defer checking allocation sites for
   newspace till merging locally buffered data.

CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org

Review URL: https://codereview.chromium.org/1577853007

Cr-Commit-Position: refs/heads/master@{#33523}

Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )

Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1632993003

Cr-Commit-Position: refs/heads/master@{#33520}

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1563213002

Cr-Commit-Position: refs/heads/master@{#33518}

- Remove semispace target capacity: It's unused and adds some unneeded
  complexity

- Enforcing decl order for SemiSpace
- Move forward declarations in spaces.h to top
- Add all members to default constructor

BUG=chromium:581076
LOG=N

Review URL: https://codereview.chromium.org/1631713002

Cr-Commit-Position: refs/heads/master@{#33515}

BUG=
R=hpayer@chromium.org

Review URL: https://codereview.chromium.org/1634513002

Cr-Commit-Position: refs/heads/master@{#33506}

- Completely rely on the concurrent sweeping state for SweepingCompleted()
- Rename the state accordingly.

CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
R=hpayer@chromium.org

Review URL: https://codereview.chromium.org/1614953002

Cr-Commit-Position: refs/heads/master@{#33490}

Revert "Revert of [profiler] Implement POC Sampling Heap Profiler (patchset #12 id:220001 of https://codereview.chromium.org/1555553002/ )"

This reverts commit 77df8659.

BUG=

Review URL: https://codereview.chromium.org/1618693004

Cr-Commit-Position: refs/heads/master@{#33473}

BUG=v8:4663
LOG=N
TBR=hpayer@chromium.org
R=ljharb@gmail.com, rossberg@chromium.org, adamk@chromium.org

Review URL: https://codereview.chromium.org/1581033002

Cr-Commit-Position: refs/heads/master@{#33450}

Revert of [profiler] Implement POC Sampling Heap Profiler (patchset #12 id:220001 of https://codereview.chromium.org/1555553002/ )

Reason for revert:
The random nature of the tests caused the following buildbot to fail: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/4724/steps/Check/logs/stdio

Original issue's description:
> [profiler] Implement POC Sampling Heap Profiler
>
> This implements a proof-of-concept sampling based heap profiler inspired by
> tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].
>
> The basic idea is the sample allocations using a randomized Poisson process. At
> any point in time we can cheaply request the set of live sample objects that
> should be a representative sample of heap. Samples include stack-traces from the
> allocation sites, making this an effective tool for memory leak debugging.
>
> Unlike AllocationTracking, this is intended to be cheap and usable online in
> production.
>
> The proof-of-concept is only sampling new-space allocations at this point.
> Support for sampling paged space and native allocations is anticipated in the
> future.
>
> [1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
> [2] http://blog.golang.org/profiling-go-programs
>
> Committed: https://crrev.com/e5a9947811db9c9e23557dbad27f8b8a349b3262
> Cr-Commit-Position: refs/heads/master@{#33448}

TBR=jochen@chromium.org,alph@chromium.org,hpayer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/1615173002

Cr-Commit-Position: refs/heads/master@{#33449}

This implements a proof-of-concept sampling based heap profiler inspired by
tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].

The basic idea is the sample allocations using a randomized Poisson process. At
any point in time we can cheaply request the set of live sample objects that
should be a representative sample of heap. Samples include stack-traces from the
allocation sites, making this an effective tool for memory leak debugging.

Unlike AllocationTracking, this is intended to be cheap and usable online in
production.

The proof-of-concept is only sampling new-space allocations at this point.
Support for sampling paged space and native allocations is anticipated in the
future.

[1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
[2] http://blog.golang.org/profiling-go-programs

Review URL: https://codereview.chromium.org/1555553002

Cr-Commit-Position: refs/heads/master@{#33448}

Also restrict how many pages are swept during slow path allocation.

BUG=chromium:524425
LOG=N

Review URL: https://codereview.chromium.org/1596343004

Cr-Commit-Position: refs/heads/master@{#33435}

R=mstarzinger@chromium.org
BUG=v8:4690
LOG=N

Review URL: https://codereview.chromium.org/1601813009

Cr-Commit-Position: refs/heads/master@{#33409}

This reverts commit 7cf64f40.

Tanks octane. Will use a different approach here.

BUG=chromium:578871, chromium:524425
LOG=N
TBR=hpayer@chromium.org

Review URL: https://codereview.chromium.org/1605813004

Cr-Commit-Position: refs/heads/master@{#33382}

This adds a handler table field to the header of our BytecodeArray
objects. The field will eventually hold a range-based handler table
similar to full-codegen code, to support exception handlong within
interpreted code.

R=oth@chromium.org
BUG=v8:4674
LOG=n

Review URL: https://codereview.chromium.org/1606493002

Cr-Commit-Position: refs/heads/master@{#33373}

R=mlippautz@chromium.org

Review URL: https://codereview.chromium.org/1583323005

Cr-Commit-Position: refs/heads/master@{#33335}