Performance problem: GC of JIT code

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Performance problem: GC of JIT code

Yves
Hi,

My recent performance measurements have confirmed again that our main
performance related issue with SpiderMonkey currently is its behaviour of
garbage collecting JIT code. I've had some discussions on IRC about that
topic in the past but I only recently became aware of how crucial this is
for performance and would like to make sure the developers are aware of
this.

Here's a link to my measurements and details about the setup, standard
deviations and distribution of results:
http://www.wildfiregames.com/forum/index.php?showtopic=18466&p=298215

To sum it up, the measurements show 13-14% performance improvement when
setting the flag "alwaysPreserveCode" in vm/Runtime.cpp from false to
true. That's total runtime of a non-visual replay including C++ code
which is not related to SpiderMonkey. If SpiderMonkey makes up 70% of
that time, it would be somewhere around 20% JS execution performance
improvement!
I've tested this with v24 months ago and there the picture was completely
different (not much improvement with this flag). It looks like most of
the performance improvements and bug fixes only really take effect in our
case if the JIT code is kept long enough.

I know that there have been improvements that allow you to keep JIT code
longer. My Question is if use cases like ours will be considered too. We
only have the scripts which are bundled with the game plus maybe some
downloadable content (mods, scenarios etc.) in the future. It might
actually be feasible to keep all script code in memory.

Some possible improvements compared to keeping all code:

1.
Have some heuristics where you set some basic parameters like if it
should try to keep the JIT code as long as possible or rather try to keep
memory usage low and do more aggressive collection. You could set a
maximum amount of memory for JIT code and one mode of collection would be
only trying to collect if that limit is exceeded.

2.
Have an API to set collection behaviour per script or function. For
example we could define that the random map generation functions are
usually just used once at the beginning of the game when the map is
generated. SpiderMonkey could decide to JIT compile parts of it because
terrain generation usually has a lot of loops and repetition. It would
benefit from JIT compiling these loops even if the whole script just runs
once. However, it would not use space in memory for keeping that code
when it will never be needed again later in game.

I hope we can get this problem fixed. Safely landing these performance
improvements would be an awesome reward for years of work on SpiderMonkey
integration and maintenance in our game. :)

Regards,
Yves

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Performance problem: GC of JIT code

Nicolas B. Pierron
Hi Yves,

On 09/14/2014 03:56 PM, Yves wrote:
 > My recent performance measurements have confirmed again that our main
 > performance related issue with SpiderMonkey currently is its behaviour of
 > garbage collecting JIT code. I've had some discussions on IRC about that
 > topic in the past but I only recently became aware of how crucial this is
 > for performance and would like to make sure the developers are aware of
 > this.
 >
 > Here's a link to my measurements and details about the setup, standard
 > deviations and distribution of results:
 > http://www.wildfiregames.com/forum/index.php?showtopic=18466&p=298215
 >
 > To sum it up, the measurements show 13-14% performance improvement when
 > setting the flag "alwaysPreserveCode" in vm/Runtime.cpp from false to
 > true. That's total runtime of a non-visual replay including C++ code
 > which is not related to SpiderMonkey. If SpiderMonkey makes up 70% of
 > that time, it would be somewhere around 20% JS execution performance
 > improvement!

We used to have the same issue for requestAnimationFrame, we
fix-it by setting a variable with the last time we called this
function (see js::NotifyAnimationActivity [1]).  This time is
then used to preserve the code for 1 second after the last call.

Also, I recall that we had a timer which triggered a full GC
every 5 minutes.  This system was based on a timer using the
interruption callback to trigger the GC.  I do not know the
status of it, but I guess we still have it in Firefox.

[1] http://dxr.mozilla.org/mozilla-central/source/js/src/jsfriendapi.cpp#421
[2] http://dxr.mozilla.org/mozilla-central/source/js/src/jsgc.cpp#3516

--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Performance problem: GC of JIT code

Yves
Am Mon, 15 Sep 2014 15:54:39 +0200 schrieb Nicolas B. Pierron:
>
> We used to have the same issue for requestAnimationFrame, we fix-it by
> setting a variable with the last time we called this function (see
> js::NotifyAnimationActivity [1]).  This time is then used to preserve
> the code for 1 second after the last call.
>
I have actually tried that already. It's quite a hack in our case because
we would have to call it in most compartments nearly all the time. If
there's only a single very bad lag-spike or something else that delays
these calls for more than a second, we loose our JIT code again. That's
too fragile IMO.

> Also, I recall that we had a timer which triggered a full GC every 5
> minutes.  This system was based on a timer using the interruption
> callback to trigger the GC.  I do not know the status of it, but I guess
> we still have it in Firefox.
>

If I understand correctly, that's a workaround to avoid keeping too much
code with js::NotifyAnimationActivity, right?

Instead of having to repeatedly call a function with no more than a
second in between, it would be much easier to just start and stop the
animation activity. However, that would still give us very little control
of what makes sense to be kept in memory and what doesn't.

Wouldn't this be worth the efforts of developing a more advanced solution?

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine