[heap] Separate out optimized code map processing.

[heap] Separate out optimized code map processing.

This separates the post-processing step for optimized code maps out of
the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
visit all candidates instead of gathering candidates during marking.

Gathering candidates during marking no longer makes sense, now that the
majority of SharedFunctionInfo objects will hold such an optimized code
map. Also it reduces complexity of the implementation. Also conflating
this mechanism with "code flushing" was confusing.

R=ulan@chromium.org

Committed: https://crrev.com/8ad6168d197dd167235c9d342ec7ce37b0daa88b
Cr-Commit-Position: refs/heads/master@{#31830}

[Michael Starzinger, 2015-11-05 13:12:07]

mstarzinger@chromium.org changed reviewers:
+ mvstanton@chromium.org, yangguo@chromium.org

[Michael Starzinger, 2015-11-05 13:12:07]

Michael & Yang: FYI.
Ulan: PTAL.

[ulan, 2015-11-05 13:23:17]

LGTM, I like it.

https://codereview.chromium.org/1426953006/diff/1/src/heap/gc-tracer.h
File src/heap/gc-tracer.h (right):

https://codereview.chromium.org/1426953006/diff/1/src/heap/gc-tracer.h#newcod...
src/heap/gc-tracer.h:112: MC_MARK_OPTIMIZED_CODE_MAPS,
Please add this to GCTracer::PrintNVP

https://codereview.chromium.org/1426953006/diff/1/src/heap/objects-visiting-i...
File src/heap/objects-visiting-inl.h (right):

https://codereview.chromium.org/1426953006/diff/1/src/heap/objects-visiting-i...
src/heap/objects-visiting-inl.h:458: MarkOptimizedCodeMap(heap, code_map);
Not related to the CL: there is a potential memory leak here if the code map is
updated during incremental marking.

[Michael Starzinger, 2015-11-05 13:51:03]

Thanks. Addressed comments.

https://codereview.chromium.org/1426953006/diff/1/src/heap/gc-tracer.h
File src/heap/gc-tracer.h (right):

https://codereview.chromium.org/1426953006/diff/1/src/heap/gc-tracer.h#newcod...
src/heap/gc-tracer.h:112: MC_MARK_OPTIMIZED_CODE_MAPS,
On 2015/11/05 13:23:17, ulan wrote:
> Please add this to GCTracer::PrintNVP

Done.

https://codereview.chromium.org/1426953006/diff/1/src/heap/objects-visiting-i...
File src/heap/objects-visiting-inl.h (right):

https://codereview.chromium.org/1426953006/diff/1/src/heap/objects-visiting-i...
src/heap/objects-visiting-inl.h:458: MarkOptimizedCodeMap(heap, code_map);
On 2015/11/05 13:23:17, ulan wrote:
> Not related to the CL: there is a potential memory leak here if the code map
is
> updated during incremental marking.

Acknowledged. As discussed offline: Yes, you are absolutely right. An entry in
the optimized code map could be updated (i.e. code field changed from undefined
to code), which would cause the optimized code map to transition from black to
gray. That would make all entries strong for the current cycle. The only true
solution to this is to migrate towards weak cells eventually. I am all in favor
of doing that at some point.

[Michael Starzinger, 2015-11-05 14:31:07]

The CQ bit was checked by mstarzinger@chromium.org

[Michael Starzinger, 2015-11-05 14:31:07]

The patchset sent to the CQ was uploaded after l-g-t-m from ulan@chromium.org
Link to the patchset: https://codereview.chromium.org/1426953006/#ps40001
(title: "Fix comment.")

[commit-bot: I haz the power, 2015-11-05 14:31:15]

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

[commit-bot: I haz the power, 2015-11-05 14:32:48]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-11-05 14:33:06]

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

[Michael Hablich, 2015-11-05 16:28:21]

A revert of this CL (patchset #3 id:40001) has been created in
https://codereview.chromium.org/1434503003/ by hablich@chromium.org.

The reason for reverting is: Breaks build:
https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20no....