
Fall cleaning: Optimizing V8 memory consumption - ivank
http://v8project.blogspot.com/2016/10/fall-cleaning-optimizing-v8-memory.html
======
blinkingled
Mostly sounds like a case of fixing up some non-optimal defaults - the real
hard part is gathering data from real world use cases which is required to
make your defaults better.

1) Reducing the V8 heap page size from 1M to 512KB ... results in 2x memory
reduction

2) The memory visualization tool helped us discover that the background parser
would keep an entire zone alive long after the code was already compiled. ...
resulted in reduced average and peak memory usage.

3) C++ compiler not packing structs optimally for V8s case - manual packing
saves some peak memory.

~~~
williadc
I'm not familiar with the "packing" concept. How does one go about manual
packing? How does it affect maintenance?

~~~
blinkingled
Compilers typically align struct fields to a boundary to favor execution
speed. This may be good for most use cases where there aren't thousands of
instances of that struct wasting a lot of memory making it a bad tradeoff.

So C/C++ compilers allow you turn this off either by specifying the data
length yourself (bit fields) and/or specifying attribute(__packed__) directive
in the case of GCC for example. In this case the packed directive resulted in
suboptimal packing so they must have gone with bit fields I suppose to do
manual packing.

~~~
puzzle
Or you might also rearrange fields of the same type to be together.

------
fenomas
Piggybacking on this, can anyone recommend an approach for finding the cause
of memory issues in v8?

In my case I'm tuning a 3D game, and the heap usage is a sawtooth pattern with
GCs about once per second. Not awful, but it would be nice to smooth it out.
But playing with Chrome's various memory profiling tools I've never been able
to discover where the allocations are coming from - the results always seem to
be dominated by apparently internal stuff (like entries called "(code deopt
data") or such). Does anyone know any good techniques for such things?

~~~
tehlike
Is the game open to public? I would like to give it a look, i have done some
amount of optimizations as a hobby.

~~~
fenomas
It's not yet, but I'm pretty sure the allocations are happening in the 3D
engine I'm using. (I mean the chrome tools aren't telling me that, but when I
let the game run without rendering the sawtooth goes away.)

Actually now that I take a second look, some relatively simple demos of the
same engine (Babylon.js) show the same sort of behavior. Some rather trivial
three.js demos do as well. I might be dealing with something that's just a
fact of life for webGL rendering.

Random example (not mine) showing a vaguely similar sawtooth of heap memory
usage:

[http://gleborgne.github.io/molvwr/#1GCN](http://gleborgne.github.io/molvwr/#1GCN)

------
caminante
I was confused by the article.

    
    
      "Reducing the V8 heap page size from 1M to 512KB results 
      in a smaller memory footprint when not many live objects 
      are present and lower overall memory fragmentation 
      up to 2x."
    

Is it common to say something's shrunk by 2x? Why not say 0.5x (or 50%, half,
etc.) I understand growth of 2x and assume this is a mistake, though I'm open
to convention.

~~~
anewhnaccount
The x means "times" as in multiply and the "lower" inverts it. You could also
say it's halved, been reduced by a half, been reduced by 50% or by 0.5. I
think if something has shrunk by 0.5x then this could even be interpreted as
it having grown 2x but this would be a pretty odd way to say something.

------
qaq
Hope they don't adversely affect Node's performance with this tuning for low
memory devices

~~~
bmodeldotcom
There is no downside to keeping the overall memory arena size down: better
cache locality, fewer stop the world collections. Node programmers have been
asking for this behavior for years.

~~~
qaq
As mentioned in the article there is no magic latency, throughput and memory
consumption are connected optimizing for one you will sacrifice a bit in the
other areas.

------
sdesimonebcn
What is the relation between the OP and previous work concerning the Ignition
interpreter? [http://v8project.blogspot.com.es/2016/08/firing-up-
ignition-...](http://v8project.blogspot.com.es/2016/08/firing-up-ignition-
interpreter.html)

------
d08ble
JS is wanted unlimited memory consumption in the language specs. JS is good,
but impossible for low-memory tasks.

~~~
CharlesW
It depends on your definition of "low-memory". The Kinoma XS JavaScript ES6
runtime[1] is designed specifically for low memory/CPU limited embedded
devices, and runs very comfortably on 200 MHz ARM devices with 512 KB RAM.

[1]
[http://kinoma.com/develop/documentation/technotes/introducin...](http://kinoma.com/develop/documentation/technotes/introducing-
the-kinomajs-open-source-implementation/)

~~~
titzer
Looks like that is ES5 only.

~~~
CharlesW
It currently scores 96.8% on the ES6 Compatibility Table hosted by kangax[1],
which is pretty good. That's native, no polyfills or transpiler.

EDIT: Kinoma claims ES6 compatibility is at 98% as of 2016-01-02.[2]

[1] [https://kangax.github.io/compat-
table/es6/](https://kangax.github.io/compat-table/es6/) [2]
[http://www.kinoma.com/develop/documentation/js6/](http://www.kinoma.com/develop/documentation/js6/)

