[Webkit-unassigned] [Bug 92198] Web Inspector: [JSC] debugging long-running scripts with conditional breakpoints consumes huge amounts of memory

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Dec 14 00:59:49 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=92198





--- Comment #8 from Yury Semikhatsky <yurys at chromium.org>  2012-12-14 01:02:09 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #2)
> > > This problem is more obvious in memory-limited environment (e.g. mobile).
> > > 
> > > The root reason is that, for failed condition of breakpoint, JSC doesn't run the EventLoop, so in a dense loop of js code, there is no chance to recycle garbage caused by evaluating the breakpoint's condition.
> > > 
> > It sounds weird that the issue is specific to breakpoint conditions. How does it work in case of eval producing a lot of garbage in a tight loop in user code?
> > 
> Sorry to reply so late, since I spent some time to investigate the related code of JSC. For the code like this:
> for (var i=0;i<0xfffff;i++) {
> ...
> eval("...");
> ...
> }
> The "EvalExecutable" is allocated just once and saved as an argument of current callFrame (Interpreter.cpp:149).
> 
> But to evaluate the condition of breakpoint, the DebuggerCallFrame::evaluate is invoked, the "EvalExecutable" is allocated every time. Maybe, because it's difficult to bind the breakpoint-condition's string with a certain callFrame.

Why JSC cannot run GC automatically during the breakpoint condition evaluation if it needs to free some memory? We need someone who understands JSC garbage collector details to look at this change.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list