On 2011/01/12 06:05:37, marklam wrote:
Søren, Mikhail,
This is the CL for the live object list (lol) heap debugging tool that I
talked
to you about previously. Currently, it is configured to be disabled by
default.
When disabled, the C++ side runtime functions are stubbed out. The JS
side
checks a flag and hides all lol artifacts.
When enabled, the lol functionality will show up in the debugger. The
basic
concept of lols are that they represent live snapshots of the heap at any
given
time. If any object within that snapshot gets GCed, the collected object
will
be removed from the live object list that captured it. If enabled but no
lols
were captured (i.e. not used), the performance impact is minimal. There
are
just a few flag checks in the GC code.
The lols also track captured objects using object ids which are
represented in
the debugger as @<object id number>. Unlike debugger #<number># handles,
lol
obj ids are persistant, but will not prevent the GC from collecting the
object.
Because the obj ids are persistant, the user can keep track of whether
certain
objects get GCed or not over time.
I've tested running it on a linux ARM build. With the lol functionality,
I
think there are some bugs (which have crept in since I last used these)
in the
retainers and path computation code. The path computation code may be
vulnerable to circular references (based on my testings). I will need to
investigate and fix those later. The rest of the functionality of
characterizing the heap and detecting leaks are all working. The object
inspection code are also all working. The known bugs are isolated within
the
lol code and does not affect the rest of v8's functionality. So, I would
like
to get this code integrated first if it meets your requirements.
BTW, this code is tested on bleeding edge r6276. I've run it against the
v8
tests and I found no failures so far.
Please let me know if there are items that I need to address in order to
get
this committed. Thanks.
Mark, thanks for your patch! I will look at it closely this week.
I have yet unpublished path computation code that seems to work well. The
only
issue that the length of paths being looked up needs to be limited, because
otherwise trying all of them takes considerable time on big web apps graphs.
http://codereview.chromium.org/6174007/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
