I might be missing some simple solution, but if I split them into two proper groups I will need to maintain some group ID and add flags which smells somewhat complicated to me.
The structures I talked were just a convenience wrappers for triples: array of handles, its length and its info. yours, anton. On Tue, Mar 15, 2011 at 12:45 AM, <[email protected]> wrote: > Yes, this makes more sense. > > I think, you can remove some duplication in code, if you store dependents as > an > object group on its own, with a flag. In this case, the code that need to > process both ordinary groups and dependent groups will remain the same, and > the > code that needs only ordinary groups can filter them by checking the flag. > > Is this what you've meant by "I am not introducing structures for handles' > collection"? > > On 2011/03/14 20:17:21, antonm wrote: >> >> Sure, may you have another look? > >> I am not introducing structures for handles' collection (length, array and > > your >> >> info object) yet, let's reserve it for a separate CL. > >> On 2011/03/14 18:33:07, Mikhail Naganov (Chromium) wrote: >> > On 2011/03/14 18:01:39, antonm wrote: >> > > Guys, >> > > >> > > may you have a look? >> > > >> > > I am esp. uneasy about all those testing utils in liveobjects and > > profiler. >> >> > >> > As we have discussed offline, tagging all objects (object + dependents) >> > with > > a >> >> > single RetainedObjectInfo (and thus, representing them as a single group >> > to >> Heap >> > profiler) is a wrong approach. >> > More correct is to define 2 separate groups, and then specify an >> unidirectional >> > dependency between them. This way, they can be accurately rendered in >> > Heap >> > profiler. > > > > http://codereview.chromium.org/6686053/ > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
