Some general observations:
1) This CL gives you snapshots of the live-bytes (i.e. foo_bytes_used) at
points
when a space is expanded. However it doesn't do the same when the space is
shrunk. I think this behavior is counter-intuitive. It might even lead to
situations where it appears there are more live-bytes than allocated memory.
2) Since this provides snapshots of the live-bytes counter, it makes it look
like the live-bytes make huge jumps, although it actually grows steadily
over
time. So if you sample with a high sampling rate over these counters, it
might
paint misleading picture.
3) Maybe the best solution is to update all of the counters only at GC
points.
This would decrease the granularity but make the overall behavior more
intuitive. WDYT?
https://chromiumcodereview.appspot.com/10657022/diff/1/src/spaces.cc
File src/spaces.cc (right):
https://chromiumcodereview.appspot.com/10657022/diff/1/src/spaces.cc#newcode559
src/spaces.cc:559: ObjectSpace space = static_cast<ObjectSpace>(1 <<
owner->identity());
The deoptimizer (i.e. Deoptimizer::CreateCode) uses this allocation
method without providing a valid owner.
https://chromiumcodereview.appspot.com/10657022/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
