Closed Bug 885226 Opened 11 years ago Closed 3 years ago

Profiler doesn't report function names for JS function properties on an object

Categories

(Core :: Gecko Profiler, defect, P5)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: MattN, Unassigned)

References

(Blocks 1 open bug)

Details

If I have an object like so: let foo = { bar: function () { … }, } The profile should show "bar" or "foo.bar" as the name of the function rather than displaying it as <Anonymous> in Cleopatra. The JS engine knows how to do this (bug 433529) and I believe the debugger supports this (bug 819049). Since the JS engine support landed, the Firefox team no longer provides function names in these cases so new code is inconvenient to profile as all the functions show as "<Anonymous>".
Jim, could you provide some pointers to what would need to be done to fix this bug?
Flags: needinfo?(jimb)
In the debugger we use the Debugger API to get to the inferred name: https://wiki.mozilla.org/Debugger#Accessor_Properties_of_the_Debugger.Object_prototype I believe the profiler could use Debugger.Object.prototype.displayName, too.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #2) > Hmm, was > http://hg.mozilla.org/mozilla-central/diff/4ebcfba34c38/js/src/vm/ > SPSProfiler.cpp supposed to fix this? That's certainly the kind of change that's supposed to give you the display names (the synthesized names like Foo.prototype.bar or whatever). I would expect this code to be making the profiler behave as requested in this bug. So something's going wrong. The first thing I would check is whether allocProfileString is indeed able to find the display names for the functions. Then we can tell whether the problem is upstream from there (the JS engine isn't setting display names correctly any more) or downstream from there (the JIT isn't generating the code to pass the names to SPSProfiler::push, or that function is failing to push them on SPSProfiler::stack_, or something like that).
Flags: needinfo?(jimb)
So, I've been noticing that this is intermittent. I sometimes see proper descriptions, sometimes not. I'm using the profiler with environment variables to dump output on shutdown; maybe some of the JS files have been unloaded when the "JS-symbolicating" code runs or something? Is that possible at all?
(In reply to :Gijs Kruitbosch from comment #5) > maybe some of the JS files have been > unloaded when the "JS-symbolicating" code runs or something? Is that > possible at all? There's no JS-symbolication code. JS provides strings which we use as-is.
(In reply to Jim Blandy :jimb from comment #4) > The first thing I would check is whether allocProfileString is indeed able > to find the display names for the functions. Then we can tell whether the > problem is upstream from there (the JS engine isn't setting display names > correctly any more) or downstream from there (the JIT isn't generating the > code to pass the names to SPSProfiler::push, or that function is failing to > push them on SPSProfiler::stack_, or something like that). Thanks Jim. Is this something you or someone else could look at shortly? This fix would really help JS profiles (especially comparison ones).
Flags: needinfo?(jimb)
I can't work on this in the short term. I think any SpiderMonkey hacker could work on this.
Flags: needinfo?(jimb)
Naveed, can someone on your team look into this? It's making it difficult to profile some Australis front-end code.
Flags: needinfo?(nihsanullah)
I think this should be closed in favor of implementing the correct ES6 feature for name property of function objects. https://bugzilla.mozilla.org/show_bug.cgi?id=883377
Blocks: 761253
Flags: needinfo?(nihsanullah)
Priority: -- → P5

I've just tried, and the profiler shows bar and its source location, so I'll call this bug fixed.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.