Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fall cleaning: Optimizing V8 memory consumption

v8project.blogspot.com

Post reply on HN
Print view View original

41–43 of 43 posts

Re: Fall cleaning: Optimizing V8 memory consumption

#41

Post by CharlesW »

titzer wrote: post #40
CharlesW wrote: post #16

Earlier quoted context omitted.

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...

Looks like that is ES5 only.

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/ [2] http://www.kinoma.com/develop/documentation/js6/

Re: Fall cleaning: Optimizing V8 memory consumption

#43

Post by iamstef »

fenomas wrote: post #33
iamstef wrote: post #30

Earlier quoted context omitted.

You may want to give the follow script a try: * https://gist.github.com/krisselden/d3ce3cbb37cc6035b0927fdbf... It flips some handy flags providing useful output, this output can quickly illuminate issues the regular tools do not (yet). Running this on the example you linked to bellow, shows that a series of functions are deopting and optimizing repeatedly. most likely causing at-least some of the sawtooth pattern yo…

Hrm. I've looked at deopts before, and I may be wrong but I think they aren't the issue. As I understand v8, it's normal at startup for hot functions to go through the opt/deopt cycle several times as the engine learns about them - and once a function does it too many times, it gets deopted permanently. For this reason I always let the game run for 10-15 seconds before I profile, figuring that by that time most of th…

> At the same time though, when I used Chrome's built-in memory profiling I see a bunch of deopt-related strings, so maybe I'm way off base

In my experience, these add up real quick and are often indicators of a larger "instability" issue that remains well after the "deopt churn" appears to settle, but continues manifests in the form of some heavy GC.

Note: many internal structures related to the JIT (IC/hidden classes/code gen etc) can themselves cause sufficient GC pressure, as can the code you described as "de-opted permanently".

Interestingly it is also possible for the above mentioned GC pressure to itself cause some fun (even more GC pressure): https://bugs.chromium.org/p/v8/issues/detail?id=5456

This may not be the root of your issue, but I would be careful to rule it out entirely to quickly.

Anyways, best of luck!

Post reply on HN