Revision: 13173
Author: [email protected]
Date: Fri Dec 7 06:06:56 2012
Log: Rollback of r13152 in trunk branch.
Let marking speed depend on the actual incremental write barrier count.
[email protected]
BUG=
Review URL: https://codereview.chromium.org/11464022
http://code.google.com/p/v8/source/detail?r=13173
Modified:
/trunk/src/incremental-marking.cc
/trunk/src/version.cc
=======================================
--- /trunk/src/incremental-marking.cc Thu Dec 6 09:32:37 2012
+++ /trunk/src/incremental-marking.cc Fri Dec 7 06:06:56 2012
@@ -881,7 +881,7 @@
// allocation), so to reduce the lumpiness we don't use the write
barriers
// invoked since last step directly to determine the amount of work to
do.
intptr_t bytes_to_process =
- marking_speed_ * Max(allocated_,
write_barriers_invoked_since_last_step_);
+ marking_speed_ * Max(allocated_, kWriteBarriersInvokedThreshold);
allocated_ = 0;
write_barriers_invoked_since_last_step_ = 0;
=======================================
--- /trunk/src/version.cc Fri Dec 7 04:40:13 2012
+++ /trunk/src/version.cc Fri Dec 7 06:06:56 2012
@@ -35,7 +35,7 @@
#define MAJOR_VERSION 3
#define MINOR_VERSION 15
#define BUILD_NUMBER 10
-#define PATCH_LEVEL 0
+#define PATCH_LEVEL 1
// Use 1 for candidates and 0 otherwise.
// (Boolean macro values are not supported by all preprocessors.)
#define IS_CANDIDATE_VERSION 0
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
