Fall cleaning: Optimizing V8 memory consumption • Hacker News Board

Re: Fall cleaning: Optimizing V8 memory consumption

#11

Post by paulddraper » Sat, Oct 08, 2016, 1:50 AM UTC

caminante wrote: post #5

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.

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

Re: Fall cleaning: Optimizing V8 memory consumption

#12

Post by d08ble » Sat, Oct 08, 2016, 2:21 AM UTC

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

Re: Fall cleaning: Optimizing V8 memory consumption

#13

Post by fenomas » Sat, Oct 08, 2016, 2:40 AM UTC

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?

Re: Fall cleaning: Optimizing V8 memory consumption

#14

Post by williadc » Sat, Oct 08, 2016, 2:43 AM UTC

blinkingled wrote: post #3

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

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

Re: Fall cleaning: Optimizing V8 memory consumption

#15

Post by blinkingled » Sat, Oct 08, 2016, 2:55 AM UTC

williadc wrote: post #14

blinkingled wrote: post #3

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

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

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.

Re: Fall cleaning: Optimizing V8 memory consumption

#16

Post by CharlesW » Sat, Oct 08, 2016, 3:15 AM UTC

d08ble wrote: post #12

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

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

Re: Fall cleaning: Optimizing V8 memory consumption

#17

Post by anewhnaccount » Sat, Oct 08, 2016, 3:35 AM UTC

caminante wrote: post #5

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.

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.

Re: Fall cleaning: Optimizing V8 memory consumption

#18

Post by puzzle » Sat, Oct 08, 2016, 3:42 AM UTC

blinkingled wrote: post #15

williadc wrote: post #14

Earlier quoted context omitted.

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

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…

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

Re: Fall cleaning: Optimizing V8 memory consumption

#19

Post by [deleted] » Sat, Oct 08, 2016, 3:50 AM UTC

puzzle wrote: post #18

blinkingled wrote: post #15

Earlier quoted context omitted.

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…

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

[deleted]

Re: Fall cleaning: Optimizing V8 memory consumption

#20

Post by bmodeldotcom » Sat, Oct 08, 2016, 4:16 AM UTC

qaq wrote: post #2

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

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.