The scavenger should never consider mark bits for promotion/copy as this creates
weird livetimes at the start of incremental marking. E.g. consider an object
marked black by the marker at the start of incremental marking. A scavenge would
promote it to the old generation although it could --and for short-living
objects actually does-- become unreachable during marking

Also, keeping this invariant significantly simplifies young generation mark
compacting as we can compare against the scavenging decision without keeping
different sets of markbits.

BUG=chromium:651354
R=hpayer@chromium.org

Review-Url: https://codereview.chromium.org/2397713002
Cr-Commit-Position: refs/heads/master@{#40026}

R=mlippautz@chromium.org
BUG=chromium:633539
TEST=cctest/test-heap/TestNewSpaceRefsInCopiedCode

Review-Url: https://codereview.chromium.org/2203783002
Cr-Commit-Position: refs/heads/master@{#38326}

It happens that a scavenger runs during incremental marking. Currently scavenger does not care about MarkCompact's mark bits. When an object is alive and marked, and at least one scavenge happens during incremental marking, the object will be copied once to the other semispace in the new_space, and then once to the old_space. For surviving objects this is useless extra work.

In our current attempts (https://codereview.chromium.org/1988623002) to ensure marked objects are scavenged, all marked objects will survive therefore there will be many objects which will be uselessly copied.

This cl modifies our promotion logic so when incremental marking is in progress, and the object is marked, we promote it unconditionally.

BUG=
LOG=no

Review-Url: https://codereview.chromium.org/2005173003
Cr-Commit-Position: refs/heads/master@{#36643}

The {force_promotion} flag causes the scavenger to move an object to the
old generation instead of to the other semi-space. We use the flag to force
the promotion of objects which are referenced by code objects.

R=ulan@chromium.org

Committed: https://crrev.com/f2a7ba6449406d0b11a245aa1f5b4981265b6f20
Cr-Commit-Position: refs/heads/master@{#36443}

Review-Url: https://codereview.chromium.org/2002013002
Cr-Commit-Position: refs/heads/master@{#36462}

Revert of [heap] Pass a force_promotion flag to the evacuation routine in the scavenger. (patchset #3 id:40001 of https://codereview.chromium.org/2002013002/ )

Reason for revert:
Need to revert JSArrayBuffer change. Please rebase and reland.

Original issue's description:
> [heap] Pass a force_promotion flag to the evacuation routine in the scavenger.
>
> The {force_promotion} flag causes the scavenger to move an object to the
> old generation instead of to the other semi-space. We use the flag to force
> the promotion of objects which are referenced by code objects.
>
> R=ulan@chromium.org
>
> Committed: https://crrev.com/f2a7ba6449406d0b11a245aa1f5b4981265b6f20
> Cr-Commit-Position: refs/heads/master@{#36443}

TBR=ulan@chromium.org,ahaas@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/2007563004
Cr-Commit-Position: refs/heads/master@{#36460}

The {force_promotion} flag causes the scavenger to move an object to the
old generation instead of to the other semi-space. We use the flag to force
the promotion of objects which are referenced by code objects.

R=ulan@chromium.org

Review-Url: https://codereview.chromium.org/2002013002
Cr-Commit-Position: refs/heads/master@{#36443}

This patch moves the wrapper code from the remembered-set to the
scavenger and the mark-compact code.

The wrapper code inspected a slot address to see if the object that
belongs to the address is in the from-space. If it was in the
from-space, then some callback was executed on the object. If the object
got move to the to-space, then the wrapper returned KEEP_SLOT, otherwise
REMOVE_SLOT.

This logic does not really belong to the remembered set, so I moved it
away from there.

R=ulan@chromium.org

Review-Url: https://codereview.chromium.org/1994933002
Cr-Commit-Position: refs/heads/master@{#36364}

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}

We use a scratchpad to remember visited allocation sites for post processing
(making tenure decisions). The previous implementation used a rooted FixedArray
with constant length (256) to remember all sites. Updating the scratchpad is a
bottleneck in any parallel/concurrent implementation of newspace evacuation.

The new implementation uses a HashMap with allocation sites as keys and
temporary counts as values. During evacuation we collect a local hashmap of
visited allocation sites. Upon merging the local hashmap back into a global one
we update potential forward pointers of compacted allocation sites.  The
scavenger can directly enter its entries into the global hashmap. Note that the
actual memento found count is still kept on the AllocationSite as it needs to
survive scavenges and full GCs.

BUG=chromium:524425
LOG=N
R=hpayer@chromium.org

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

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

BUG=none
R=ishell@chromium.org,hpayer@chromium.org
LOG=n

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

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

This moves scavenging functionality into a separate component so that
neither the scavenger nor objects-visiting need to be exposed outside
the heap.

R=hpayer@chromium.org,mlippautz@chromium.org

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

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