Issue 10974003: Make the speed of incrmental marking depend also on the rate

Keyboard Shortcuts

	File
u :	up to issue
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line

	Issue
u :	up to list of issues
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue

Issue 10974003: Make the speed of incrmental marking depend also on the rate (Closed)

Created:
8 years, 3 months ago by Erik Corry

Modified:
8 years, 2 months ago

Reviewers:
Michael Starzinger

CC:
v8-dev

Base URL:
http://v8.googlecode.com/svn/branches/bleeding_edge/

Visibility:
Public.

More Reviews

Description

Make the speed of incremental marking depend also on the rate at which we are hitting expensive write barrier operations, not just on the rate of allocation. Committed: https://code.google.com/p/v8/source/detail?r=12618

Patch Set 1 #

Patch Set 2 : #

Patch Set 3 : #

Total comments: 1

Created: 8 years, 3 months ago

Download [raw] [tar.bz2]

	Unified diffs	Side-by-side diffs	Delta from patch set	Stats (+122 lines, -41 lines)			Patch
M	src/arm/code-stubs-arm.cc	View	1	1 chunk	+10 lines, -0 lines	0 comments	Download
M	src/heap.cc	View	1	1 chunk	+2 lines, -1 line	0 comments	Download
M	src/ia32/code-stubs-ia32.cc	View	1	1 chunk	+11 lines, -0 lines	0 comments	Download
M	src/incremental-marking.h	View	1	3 chunks	+12 lines, -10 lines	0 comments	Download
M	src/incremental-marking.cc	View	1	11 chunks	+52 lines, -26 lines	1 comment	Download
M	src/incremental-marking-inl.h	View	1	1 chunk	+1 line, -1 line	0 comments	Download
M	src/spaces.h	View	1	5 chunks	+21 lines, -2 lines	0 comments	Download
M	src/spaces.cc	View	1	2 chunks	+2 lines, -1 line	0 comments	Download
M	src/x64/code-stubs-x64.cc	View	1	1 chunk	+11 lines, -0 lines	0 comments	Download

Messages

Total messages: 2 (0 generated)

Expand Messages | Collapse Messages

Michael Starzinger

8 years, 2 months ago (2012-09-26 08:06:37 UTC) #2

LGTM (with one comment), if it doesn't regress Splay, Spinning Balls or any
other GC benchmark.

https://codereview.chromium.org/10974003/diff/10003/src/incremental-marking.cc
File src/incremental-marking.cc (right):

https://codereview.chromium.org/10974003/diff/10003/src/incremental-marking.c...
src/incremental-marking.cc:791: write_barriers_invoked_since_last_step_ <
kIncrementalMarkingThreshold) {
Even if the two thresholds we are comparing against happen to have the same
value, I think we should still use two different constants here (one for
allocation and one for WB counts).

Expand Messages | Collapse Messages