After performing
v8::V8::LowMemoryNotification();
while( !v8::V8::IdleNotification());
I then dumped the leak report and the only one in the domain of V8 is
this which seems innocuous.
---------- Block 2506 at 0x00534370: 12 bytes ----------
A total of 14 leaks match this size and call stack. Showing only the
first one.
Call Stack:
d:\v8\3.2.2.1\src\serialize.cc (995):
v8::internal::Deserializer::ReadChunk
d:\v8\3.2.2.1\src\serialize.cc (725):
v8::internal::Deserializer::ReadObject
d:\v8\3.2.2.1\src\serialize.cc (912):
v8::internal::Deserializer::ReadChunk
d:\v8\3.2.2.1\src\serialize.cc (725):
v8::internal::Deserializer::ReadObject
d:\v8\3.2.2.1\src\serialize.cc (912):
v8::internal::Deserializer::ReadChunk
d:\v8\3.2.2.1\src\serialize.cc (704):
v8::internal::Deserializer::VisitPointers
d:\v8\3.2.2.1\src\heap.cc (4359):
v8::internal::Heap::IterateStrongRoots
d:\v8\3.2.2.1\src\serialize.cc (670):
v8::internal::Deserializer::Deserialize
d:\v8\3.2.2.1\src\v8.cc (124): v8::internal::V8::Initialize
d:\v8\3.2.2.1\src\snapshot-common.cc (43):
v8::internal::Snapshot::Deserialize
d:\v8\3.2.2.1\src\snapshot-common.cc (56):
v8::internal::Snapshot::Initialize
d:\v8\3.2.2.1\src\api.cc (3355): v8::V8::Initialize
This gave me an idea, so I changed the app to do while( !
v8::V8::IdleNotification()); every 2 seconds during execution. No
difference, the GC gradually gets slower.
I also commented out my calls to
AdjustAmountOfExternalAllocatedMemory. Ultimately the same problem:
"pause" slowly increases and the system comes to a standstill.
However, with AdjustAmountOfExternalAllocatedMemory enabled I only see
mark/sweep but without it the GC output showed mark operations
interspersed with mark/sweep every couple of seconds, after a minute
or so this changed to sweep operations interspersed with mark/sweep
operations (no mark-only operations).
On Mar 17, 10:59 am, "[email protected]"
<[email protected]> wrote:
> Hello!
>
> My application (using V8 3.2.2.1) starts off running very well but
> gradually slows down. My guess is I have some form of leak which is
> causing the GC to have to check more and more over time, but its not
> clear to me how I can best track it down.
>
> Profiling shows IterateStrongRoots starts to swamp the CPU after a
> couple of minutes.
>
> I enabled -trace-gc --trace-gc-nvp:
>
> ~0 seconds: pause=26 mutator=128 gc=ms external=7 mark=12 sweep=7
> sweepns=7 compact=0 total_size_before=9443740 total_size_after=959396
> holes_size_before=317796 holes_size_after=412116 allocated=8446216
> promoted=70832
> 60 seconds: pause=67 mutator=126 gc=ms external=14 mark=39 sweep=14
> sweepns=13 compact=0 total_size_before=9410524 total_size_after=988920
> holes_size_before=425740 holes_size_after=480068 allocated=8441648
> promoted=77816
> 120 seconds: pause=109 mutator=120 gc=ms external=23 mark=66 sweep=20
> sweepns=20 compact=0 total_size_before=9494728
> total_size_after=1081072 holes_size_before=397320
> holes_size_after=420880 allocated=8440584 promoted=174032
>
> Although I don't understand everything it is dumping, "pause" is
> increasing which I assume means GC is talking longer over time
> confirming what profiling already showed, but do the other values hint
> of the problem? Are there any other flags that might help reveal the
> problem?
>
> The application uses AdjustAmountOfExternalAllocatedMemory to report
> external memory use (which is substantial) and I initially suspected
> this as the culprit, however the blocks are freed and the persistent
> handles Disposed and Cleared.
>
> I've check for memory leaks using external tools, and it has found
> some however this has little meaning until I can coordinate the system
> to stop, ensure GC has done all it can so all that is left are real
> leaks and get the report.
>
> Any pointers would be great!
>
> Stuart.
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
