Is there any way we can understand which parts of the developer's code are causing a lot of temporary allocations? That is, stats about which objects created by the developer were picked up in GC?
More context: At present we have GC records showing in the timeline, which is great. What it doesn't tell you is what was picked up in GC, specifically that which relates back to your code. So if you're using a lot of temporary variables or anonymous functions somewhere in your code it is very difficult to find, especially if you have a large codebase. A suggestion here might be to in some way track the allocations so that you can see the top scoring items. So in effect if a developer is looping through an array and effectively assigning the same logical function as a callback then we can point at that to say "this function is being allocated a lot".
(In reply to comment #0) > Is there any way we can understand which parts of the developer's code are causing a lot of temporary allocations? That is, stats about which objects created by the developer were picked up in GC? Can you elaborate on what do you mean by picked up in GC? Is it about the objects that survive scavenge pass? Or is it a set of objects that were unreachable during the pass? (In reply to comment #1) > More context: > > At present we have GC records showing in the timeline, which is great. What it doesn't tell you is what was picked up in GC, specifically that which relates back to your code. So if you're using a lot of temporary variables or anonymous functions somewhere in your code it is very difficult to find, especially if you have a large codebase. A suggestion here might be to in some way track the allocations so that you can see the top scoring items. So in effect if a developer is looping through an array and effectively assigning the same logical function as a callback then we can point at that to say "this function is being allocated a lot". So if we show the heap stats at point A and then at point B. Do you mean at point B in addition to total js heap size we should show how many object that were alive at point A and survived at point B + number of objects that were allocated between A and B and still alive at the point B? Or do you also see how many objects were collected since point A?
(In reply to comment #2) > (In reply to comment #0) > > Is there any way we can understand which parts of the developer's code are causing a lot of temporary allocations? That is, stats about which objects created by the developer were picked up in GC? > > Can you elaborate on what do you mean by picked up in GC? Is it about the objects that survive scavenge pass? Or is it a set of objects that were unreachable during the pass? The request I get from developers is that they want to see what objects (that they created) were picked up in a GC pass. So, as an example, if they were looping through an array and in each pass created a bunch of new objects, we should expect to see those get picked up by GC. Their thinking is that if they can see where their code is especially garbagey they can remedy it by making different choices in their JS. > > > (In reply to comment #1) > > More context: > > > > At present we have GC records showing in the timeline, which is great. What it doesn't tell you is what was picked up in GC, specifically that which relates back to your code. So if you're using a lot of temporary variables or anonymous functions somewhere in your code it is very difficult to find, especially if you have a large codebase. A suggestion here might be to in some way track the allocations so that you can see the top scoring items. So in effect if a developer is looping through an array and effectively assigning the same logical function as a callback then we can point at that to say "this function is being allocated a lot". > > So if we show the heap stats at point A and then at point B. Do you mean at point B in addition to total js heap size we should show how many object that were alive at point A and survived at point B + number of objects that were allocated between A and B and still alive at the point B? Or do you also see how many objects were collected since point A? Good question. I guess what I'm driving at is identifying how garbagey (for want of a better phrase) parts of the code are. So if there's a part of my code that is run very often that makes a lot of temporary allocations that get picked up it would be helpful to know that piece of code is responsible for more garbage than other parts of my code. So the use-case I'm getting at is not necessarily which objects survived or why so much as where the hotspots are in the code where I could try to avoid as much garbage being created. Does that help?
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > Is there any way we can understand which parts of the developer's code are causing a lot of temporary allocations? That is, stats about which objects created by the developer were picked up in GC? > > > > Can you elaborate on what do you mean by picked up in GC? Is it about the objects that survive scavenge pass? Or is it a set of objects that were unreachable during the pass? > > The request I get from developers is that they want to see what objects (that they created) were picked up in a GC pass. So, as an example, if they were looping through an array and in each pass created a bunch of new objects, we should expect to see those get picked up by GC. Their thinking is that if they can see where their code is especially garbagey they can remedy it by making different choices in their JS. > Generating a lot of garbage should NOT affect GC performance. V8's scavenger copies only alive objects so it doesn't matter how many garbage is there. > > > > > > (In reply to comment #1) > > > More context: > > > > > > At present we have GC records showing in the timeline, which is great. What it doesn't tell you is what was picked up in GC, specifically that which relates back to your code. So if you're using a lot of temporary variables or anonymous functions somewhere in your code it is very difficult to find, especially if you have a large codebase. A suggestion here might be to in some way track the allocations so that you can see the top scoring items. So in effect if a developer is looping through an array and effectively assigning the same logical function as a callback then we can point at that to say "this function is being allocated a lot". > > > > So if we show the heap stats at point A and then at point B. Do you mean at point B in addition to total js heap size we should show how many object that were alive at point A and survived at point B + number of objects that were allocated between A and B and still alive at the point B? Or do you also see how many objects were collected since point A? > > Good question. I guess what I'm driving at is identifying how garbagey (for want of a better phrase) parts of the code are. So if there's a part of my code that is run very often that makes a lot of temporary allocations that get picked up it would be helpful to know that piece of code is responsible for more garbage than other parts of my code. > > So the use-case I'm getting at is not necessarily which objects survived or why so much as where the hotspots are in the code where I could try to avoid as much garbage being created. > > Does that help? I got the idea. But for the reason I described above I think they are starting with wrong premises. They shouldn't bother about amount of the garbage produced by their code. V8's GC should collect short-living objects really fast. Do they have evidences of the opposite?
Paul, do you have a good testcase of something that triggers a fair amount of GC pause action? Yury, I think the issue at hand is that in many cases, the GC sweeps will be long enough (and/or often enough) that it stutters the action of the page. From a developer POV, solving this is mostly guessing with no real leads. The thrust here is to provide some insight based on what we know about the garbage so the developer can make a better decision and avoid frequent and heavy GC sweeps that stall the app.
CC
<rdar://problem/19106802>
Don't think this bug is relevant any more, or at least the title is too vague to make progress. Please retitle or file a new bug that's applicable now that we have heap profiler.