Hi Chris, > I enabled these flags but I am not seeing any additional TTY spew or a > data log file generated on the device (however we are building using > ANT and I could have just screwed something up).
It should just print things to stdout when enabled. You can try editing flag-definitions.h to turn these flags on during compile time. Alternatively you can call v8::V8::SetFlagsFromString to pass them to V8. > The pauses where the same (about 1~2 ms per SCAVENGER Sweep) but the > difference is with this old version of V8 the exact same Javascript > code would not trigger a MARK_COMPRESS sweep. So did the old version only trigger scavenges? Or did it trigger scavenges and mark-sweeps but no mark-compacts? > Another thing I tried was just forcing all GC to SCAVENGER. This had > a much better impact for our use case. While the SCAVENGER time jump > from 1~2 ms up to about 4~5 ms it did this only 1 per second and the > game ran very smoothly. I have now exposed a custom flag in our > version of V8 to turn off MARK_COMPRESS from Javascript code so that > games when they are in long wait situations (waiting for file IO or > Network Messaging) can turn on MARK_COMPRESS and if they are in a > performance critical area they can turn it off. If you disable MARK_COMPACTOR then your app might start accumulating garbage because scavenger can only collect things in the young generation. Also if you disable MARK_COMPACTOR entirely your app will just crash with OOM when V8 hits the allocation limit in oldspace because none of the GCs it will force will free any memory in the old space. You can try to run app with --never-compact to disable compaction phase of the mark-sweep collector to see whether it improves situation or not. This will lead to fragmentation but is much more stable then disabling full collection entirely. -- Vyacheslav Egorov On Tue, Aug 30, 2011 at 6:52 PM, Chris Jimison <[email protected]> wrote: > Hi Vyacheslav, > > Sorry I took so long to get back to this. > >> What version were you using before upgrading to HEAD and how long were >> pauses at that version? > > We where using a very old version of V8. I would say from around > January/February of 2010. The person who I inherited this code from > did not leave an SVN revision number anywhere I can find (and it looks > like they removed any reference files inside of V8 that had this > information). > >> how long were pauses at that version? > > The pauses where the same (about 1~2 ms per SCAVENGER Sweep) but the > difference is with this old version of V8 the exact same Javascript > code would not trigger a MARK_COMPRESS sweep. However when I upgraded > V8 I am now seeing the MARK_COMPRESS trigger every 10 sec or so which > introduces a very noticeable frame hitch. > >> Can you share a bit more about your use of V8? > > Sure. So we have a native C++ game engine that handles all of our > lower level logic (rendering with OpenGL, managing device touches, > etc, etc) and once a GL frame we send a large Command String to the V8 > engine for processing (it has to be a string currently in order for us > to maintain compatibility with iOS which does not use V8) and once the > Javascript has completed the frame tick it will send back a Command > String for the C++ engine to process. > > The general take away here is we are VERY string heavy in our > processing. > >> It seems that promotion rate is not high (judging from 1-2ms >> scavenging pauses) but it's hard to say anything without looking at GC >> logs. (e.g. --trace-gc, --trace-gc-verbose ones; plus maybe some >> additional debug prints in Heap::SelectGarbageCollector to see why V8 >> chooses MARK_COMPACTOR). > > I enabled these flags but I am not seeing any additional TTY spew or a > data log file generated on the device (however we are building using > ANT and I could have just screwed something up). I did put some debug > prints around the SelectGarbageCollector and found we are hitting the > following case: > > // Is enough data promoted to justify a global GC? > if (OldGenerationPromotionLimitReached()) { > isolate_->counters()->gc_compactor_caused_by_promoted_data()- >>Increment(); > return MARK_COMPACTOR; > } > > Interesting notes: > > One thing I am in the process of doing is moving all our string > process messaging into C++. This way the string objects can be more > tightly managed and we keep the uber long frame command string out of > V8 memory. This had a positive impact for us in that it increased the > amount of time from 10 sec to about 45 sec between MARK_COMPRESS > sweeps. However the MARK_COMPRESS still took about 200ms. > > Another thing I tried was just forcing all GC to SCAVENGER. This had > a much better impact for our use case. While the SCAVENGER time jump > from 1~2 ms up to about 4~5 ms it did this only 1 per second and the > game ran very smoothly. I have now exposed a custom flag in our > version of V8 to turn off MARK_COMPRESS from Javascript code so that > games when they are in long wait situations (waiting for file IO or > Network Messaging) can turn on MARK_COMPRESS and if they are in a > performance critical area they can turn it off. > > I am a little nervous about this direction. Can you foresee any major > issues I may run into with such a change? Some of the risk I am > thinking about are Heap fragmentation issues and slower object > allocation times. > > Also any general suggestion/comments would be greatly appreciated and > thanks again for your help! > > -Chris > > On Aug 22, 1:08 pm, Vyacheslav Egorov <[email protected]> wrote: >> Hi Chris, >> >> What version were you using before upgrading to HEAD and how long were >> pauses at that version? If there was a major degradation we are very >> interested in reproducing it. >> >> Can you share a bit more about your use of V8? >> >> Do you use it inside the browser or do you embed it into your >> (C/C++/Java) game directly? >> >> If you want to reduce GC cost we'll first need to understand what >> exactly is causing (compacting) GCs. >> >> It seems that promotion rate is not high (judging from 1-2ms >> scavenging pauses) but it's hard to say anything without looking at GC >> logs. (e.g. --trace-gc, --trace-gc-verbose ones; plus maybe some >> additional debug prints in Heap::SelectGarbageCollector to see why V8 >> chooses MARK_COMPACTOR). >> >> -- >> Vyacheslav Egorov, Software Engineer, V8 Team >> Google Denmark ApS >> >> >> >> >> >> >> >> On Mon, Aug 22, 2011 at 8:01 PM, Chris Jimison <[email protected]> wrote: >> > Hi all, >> >> > We have a game engine the uses V8 on Android based phones. I have >> > just upgraded our version of V8 to use the current stable SVN line and >> > I am seeing a HUGE slowdown on the GC. When the GC does a >> > MARK_COMPACTOR run I am seeing times jump up to 175 ms on a Nexus S >> > phone (one of the faster android based phones) however non >> > MARK_COMPACTOR times are at about 1-2 ms. The MARK_COMPACTOR sweep >> > happens about once every 10 - 15 seconds for us and it introduces a >> > very noticeable frame rate hitch. >> >> > So I have a couple of questions for the group. >> >> > 1) Is there anything I can do to potentially amortize this cost accost >> > multiple frames (or GC calls)? >> > 2) If not is there anyway I can speed this up? >> >> > Thank you so much for any help or insights. >> >> > -Chris >> >> > -- >> > v8-users mailing list >> > [email protected] >> >http://groups.google.com/group/v8-users > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
