Normalizing source file names before calculating hash by extracting the last component of the file path.

This hash is sent as TrackedObject.source_file_name_hash field.

This solves the problem described in the bug to a degree that we can build a functioning prototype for the server-side analysis tool. The tool will use (filename:line) pair to identify a piece of code that posts a task, and extract parameters to PostTask (and similar) functions to conveniently identify the task.

This solution is not final because the short filenames are not unique, and we’ll have about 6 conflicting pairs. This is OK for the proof-of-concept tool; further development might go in 1 of 2 different directions:
1. We like the results of the (file, line) method mentioned above, and we improve this solution, for example, by renaming files to make them unique.
2. We don’t like it, probably because of inconsistency of names on the server-side tool and the chrome://profiler page, and because it doesn’t show task entrypoints when the closure is created outside of the PostTask parameters list. In this case, we may want to explore adding an identifying parameter to the closure constructor. I’m not going to dive too deep into this, but we have a design for this. Anyways, in this case, we won’t use filename to identify tasks, and the fact that they are not unique will be OK.

For the record, there were other alternatives to extracting the last component, mainly:
1. Post-preprocessing (sic!) or compile-time or post-compile step that normalizes file names.
The issue was the high price (may be weeks of work), which is not OK for a proof-of-concept tool. For example, if we choose later to pass ID in the closure, this work would be wasted.

2. Identify the task by PC (program counter) instead of (file, line). This would require extending the UMA with a map of addresses of loaded modules, per process, and add 2 fields to TrackedObject: PC and module ID. This may be too much for a prototype. There also are some concerns regarding the server-side part of this approach.

BUG=357787

Review URL: https://codereview.chromium.org/217483006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@261407 0039d316-1c4b-4281-b951-d872f2087c98

0 files changed, 0 insertions, 0 deletions