- 05 Feb, 2016 2 commits
-
-
cbruni authored
- 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}
-
mvstanton authored
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}
-
- 04 Feb, 2016 3 commits
-
-
mvstanton authored
(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}
-
yangguo authored
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}
-
mvstanton authored
BUG= Review URL: https://codereview.chromium.org/1647123002 Cr-Commit-Position: refs/heads/master@{#33718}
-
- 03 Feb, 2016 2 commits
-
-
hablich authored
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}
-
hablich authored
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}
-
- 02 Feb, 2016 2 commits
-
-
mlippautz authored
BUG=chromium:524425 LOG=N Review URL: https://codereview.chromium.org/1653973003 Cr-Commit-Position: refs/heads/master@{#33668}
-
mlippautz authored
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}
-
- 29 Jan, 2016 1 commit
-
-
jkummerow authored
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}
-
- 28 Jan, 2016 3 commits
-
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/1649653004 Cr-Commit-Position: refs/heads/master@{#33593}
-
yangguo authored
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}
-
hpayer authored
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}
-
- 27 Jan, 2016 4 commits
-
-
mvstanton authored
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}
-
mlippautz authored
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}
-
mvstanton authored
(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}
-
machenbach authored
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}
-
- 26 Jan, 2016 5 commits
-
-
mlippautz authored
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}
-
mvstanton authored
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}
-
mvstanton authored
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}
-
mlippautz authored
- 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}
-
mlippautz authored
BUG= R=hpayer@chromium.org Review URL: https://codereview.chromium.org/1634513002 Cr-Commit-Position: refs/heads/master@{#33506}
-
- 25 Jan, 2016 1 commit
-
-
mlippautz authored
- 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}
-
- 22 Jan, 2016 2 commits
-
-
ofrobots authored
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}
-
caitpotter88 authored
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}
-
- 21 Jan, 2016 3 commits
-
-
ofrobots authored
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}
-
ofrobots authored
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}
-
mlippautz authored
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}
-
- 20 Jan, 2016 1 commit
-
-
yangguo authored
R=mstarzinger@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1601813009 Cr-Commit-Position: refs/heads/master@{#33409}
-
- 19 Jan, 2016 1 commit
-
-
mlippautz authored
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}
-
- 18 Jan, 2016 1 commit
-
-
mstarzinger authored
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}
-
- 15 Jan, 2016 4 commits
-
-
mstarzinger authored
R=mlippautz@chromium.org Review URL: https://codereview.chromium.org/1583323005 Cr-Commit-Position: refs/heads/master@{#33335}
-
jochen authored
That way, we don't have to implement the fast <-> slow migration logic, and we don't allocate in-object properties anyways BUG=chromium:571365 R=verwaest@chromium.org,neis@chromium.org LOG=n Review URL: https://codereview.chromium.org/1582773003 Cr-Commit-Position: refs/heads/master@{#33328}
-
mlippautz authored
Those counters will be incremented concurrently during parallel evacuation of newspace. This change makes sure we do the updates atomically. Note that actual reasoning about them happens sequentially on the main thread. BUG=chromium:524425 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/1585843010 Cr-Commit-Position: refs/heads/master@{#33326}
-
mlippautz authored
It is only used locally when exempting pages from the store buffer. This use case can be replaced with a hashmap at the call site. BUG=chromium:524425 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/1593583002 Cr-Commit-Position: refs/heads/master@{#33324}
-
- 14 Jan, 2016 1 commit
-
-
mlippautz authored
BUG=chromium:524425 LOG=N Review URL: https://codereview.chromium.org/1588823003 Cr-Commit-Position: refs/heads/master@{#33302}
-
- 12 Jan, 2016 2 commits
-
-
mlippautz authored
Failing to do so results in out-of-date marking information, because live bytes is not properly adjusted. This CL adds support for right trimming ByteArray and properly DCHECKs that we do not left trim ByteArray (as we already do for FixedTypedArrayBase). BUG= Review URL: https://codereview.chromium.org/1577263003 Cr-Commit-Position: refs/heads/master@{#33252}
-
mlippautz authored
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}
-
- 11 Jan, 2016 2 commits
-
-
hpayer authored
This CL changes the color for encoding black and grey. Moreover, it introduces a higher level live object iterator. BUG=chromium:561449 LOG=n Review URL: https://codereview.chromium.org/1517993003 Cr-Commit-Position: refs/heads/master@{#33208}
-
mlippautz authored
A concurrent sweeper thread can access the same markbit cell as the main thread during right trimming a fixed array, resulting in a data race on a markbit cell. Previously we checked whether we were currently marking incrementally, filtering out this case. The current check has the benefit of keeping live_bytes accurate (modulo other bugs) until the sweeper starts. BUG=chromium:576193 LOG=N Review URL: https://codereview.chromium.org/1576853002 Cr-Commit-Position: refs/heads/master@{#33203}
-