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
