On 2011/01/12 10:01:37, Michail Naganov wrote:
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.
Hi Mark,
I looked at the code, and I think I built up an understanding of
your approach, and it looks great. For the purpose of
committing, please separate your CL into smaller pieces and try
to write some unit tests. I can propose the following partition:
- list.h, list-inl.h (bsearch)
- utils.cc, v8utils.h, platform.h, .cc (mmapped ext. strings -- nice idea,
btw!)
- liveobjectlist.h, .cc, flag-definitions.h
- inspector.h, .cc
- heap.cc, mark-compact.cc, spaces.cc (wirings)
- runtime.h, .cc, debug-debugger.js, d8.cc, .js (interface)
- SConstruct, SConscript (turn on)
Some general comments:
1. Please run tools/presubmit.py to fix all easy to find style violations.
2. Please consider merging TracePathToRoot bach with Heap implementation.
As I understand, the latter is also used for debugging purposes only.
3. Listing object types in inspector.h looks fragile to me. Is it possible
for you to reuse objects-printer.cc?
http://codereview.chromium.org/6174007/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
