6 ms·

Fall cleaning: Optimizing V8 memory consumption

152 points by ivank 10y ago

caminante 10y ago
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.
- ASalazarMX 10y ago
  It's confusing. I'd think it means it shrunk 0-2 times by an indeterminate amount.
- lawnchair_larry 10y ago
  Because it grew by 0.5x ;)
- paulddraper 10y ago
  Shrinkage of 2x is the inverse of growth by 2x. I.e. shrinking 2x and then growing 2x would bring you to the original. Though in this specific case, I would have simply said "halved".
- anewhnaccount 10y ago
  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 10y ago
Hope they don't adversely affect Node's performance with this tuning for low memory devices
- lytedev 10y ago
  Couldn't node simply tell V8 to use the earlier defaults if it doesn't have its own tunings already?
- hajile 10y ago
  Mozilla's memory project a while ago showed that there's often a lot of low hanging fruit if it hasn't been a big focus. V8 uses a lot of memory in comparison in my experience. I think this should be generally without a downside.
- bmodeldotcom 10y ago
  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 10y ago
    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.
- natorion 10y ago
  According to tests it doesn't. The heap memory optimization will only trigger on mobile devices <512MB ram. The zone memory improvements shouldn't have a negative effect.
blinkingled 10y ago
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.
- deleted 10y ago
  [deleted]
- williadc 10y ago
  I'm not familiar with the "packing" concept. How does one go about manual packing? How does it affect maintenance?
  - blinkingled 10y ago
    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 10y ago
      Or you might also rearrange fields of the same type to be together.
      - deleted 10y ago
        [deleted]
  - 10y ago
fenomas 10y ago
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 10y ago
  Is the game open to public? I would like to give it a look, i have done some amount of optimizations as a hobby.
  - alooPotato 10y ago
    hey tehlike - I work on streak.com and we have some pretty interesting memory challenges being a full blown web app running inside of another very complex web app (gmail). Any interest in poking around and helping us with memory issues?
  - fenomas 10y ago
    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
- RKoutnik 10y ago
  Usually that's because you're creating and disposing of a lot of objects in your game loop. Look into initializing a lot of objects at the start and reusing 'em (usually called object pooling). I'd love to take a look deeper - contact info is in my profile if you're interested.
deleted 10y ago
[deleted]
d08ble 10y ago
JS is wanted unlimited memory consumption in the language specs. JS is good, but impossible for low-memory tasks.
- CharlesW 10y ago
  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/introducing-the-kinomajs-open-source-implementation/ http://kinoma.com/develop/documentation/technotes/introducin...
  - titzer 10y ago
    Looks like that is ES5 only.
    - CharlesW 10y ago
      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/
- tracker1 10y ago
  I've run node tasks that run in pretty low memory... when processing streams I'll often use the command-line option to expose gc, and force it after each item... runs very light that way.
sdesimonebcn 10y ago
What is the relation between the OP and previous work concerning the Ignition interpreter? http://v8project.blogspot.com.es/2016/08/firing-up-ignition-interpreter.html http://v8project.blogspot.com.es/2016/08/firing-up-ignition-...

152 points by ivank 10y ago

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.

ASalazarMX 10y ago
It's confusing. I'd think it means it shrunk 0-2 times by an indeterminate amount.
lawnchair_larry 10y ago
Because it grew by 0.5x ;)
paulddraper 10y ago
Shrinkage of 2x is the inverse of growth by 2x. I.e. shrinking 2x and then growing 2x would bring you to the original. Though in this specific case, I would have simply said "halved".
anewhnaccount 10y ago
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 10y ago

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

lytedev 10y ago
Couldn't node simply tell V8 to use the earlier defaults if it doesn't have its own tunings already?
hajile 10y ago
Mozilla's memory project a while ago showed that there's often a lot of low hanging fruit if it hasn't been a big focus. V8 uses a lot of memory in comparison in my experience. I think this should be generally without a downside.
bmodeldotcom 10y ago
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 10y ago
  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.
natorion 10y ago
According to tests it doesn't. The heap memory optimization will only trigger on mobile devices <512MB ram. The zone memory improvements shouldn't have a negative effect.

blinkingled 10y ago

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.

deleted 10y ago
[deleted]
williadc 10y ago
I'm not familiar with the "packing" concept. How does one go about manual packing? How does it affect maintenance?
- blinkingled 10y ago
  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 10y ago
    Or you might also rearrange fields of the same type to be together.
    - deleted 10y ago
      [deleted]
- 10y ago

fenomas 10y ago

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 10y ago
Is the game open to public? I would like to give it a look, i have done some amount of optimizations as a hobby.
- alooPotato 10y ago
  hey tehlike - I work on streak.com and we have some pretty interesting memory challenges being a full blown web app running inside of another very complex web app (gmail). Any interest in poking around and helping us with memory issues?
- fenomas 10y ago
  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
RKoutnik 10y ago
Usually that's because you're creating and disposing of a lot of objects in your game loop. Look into initializing a lot of objects at the start and reusing 'em (usually called object pooling). I'd love to take a look deeper - contact info is in my profile if you're interested.

deleted 10y ago

[deleted]

d08ble 10y ago

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

CharlesW 10y ago
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/introducing-the-kinomajs-open-source-implementation/ http://kinoma.com/develop/documentation/technotes/introducin...
- titzer 10y ago
  Looks like that is ES5 only.
  - CharlesW 10y ago
    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/
tracker1 10y ago
I've run node tasks that run in pretty low memory... when processing streams I'll often use the command-line option to expose gc, and force it after each item... runs very light that way.

sdesimonebcn 10y ago

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