657140 - Tune heap growth factor

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Gregor Wagner [:gwagner]]

Recent GC improvements allow us to perform GCs more often.
Tighter heap growth shouldn't significantly decrease benchmark scores any more.
We should try to tune the GC parameters for less memory consumption again.

Comment 1

[Gregor Wagner [:gwagner]]

Currently we perform 67 GCs during the web-based v8 benchmark on my MBP.
We use 487 Chunks (because of splay) and get a score of about 4870.

If we reduce the heap growth factor to 2.5 instead of 3 we perform 79 GCs.
We use 407 Chunks and get a score of 4820.

Seems like we should take this regression in favor of the smaller footprint.
I will look at other memory intensive applications. 

Trunk (Heap Growth factor 3.0):
Score: 4877
Richards: 8127
DeltaBlue: 5170
Crypto: 8756
RayTrace: 4160
EarleyBoyer: 4606
RegExp: 1638
Splay: 5688

Heap Growth factor 2.5:
Score: 4821
Richards: 8123
DeltaBlue: 4886
Crypto: 8713
RayTrace: 4030
EarleyBoyer: 4646
RegExp: 1635
Splay: 5721

Heap Growth factor 2.0:
Score: 4601
Richards: 8162
DeltaBlue: 4241
Crypto: 8708
RayTrace: 3726
EarleyBoyer: 4653
RegExp: 1577
Splay: 5297

Comment 2

[David Mandelin [:dmandelin]]

(In reply to comment #1)
> Currently we perform 67 GCs during the web-based v8 benchmark on my MBP.
> We use 487 Chunks (because of splay) and get a score of about 4870.
> 
> If we reduce the heap growth factor to 2.5 instead of 3 we perform 79 GCs.
> We use 407 Chunks and get a score of 4820.
> 
> Seems like we should take this regression in favor of the smaller footprint.
> I will look at other memory intensive applications. 

How big is a chunk again? And how long do we hold on to the extra 80 chunks?

Comment 3

[Gregor Wagner [:gwagner]]

(In reply to comment #2)
> (In reply to comment #1)
> > Currently we perform 67 GCs during the web-based v8 benchmark on my MBP.
> > We use 487 Chunks (because of splay) and get a score of about 4870.
> > 
> > If we reduce the heap growth factor to 2.5 instead of 3 we perform 79 GCs.
> > We use 407 Chunks and get a score of 4820.
> > 
> > Seems like we should take this regression in favor of the smaller footprint.
> > I will look at other memory intensive applications. 
> 
> How big is a chunk again? And how long do we hold on to the extra 80 chunks?

const size_t GC_CHUNK_SHIFT = 20;
const size_t GC_CHUNK_SIZE = size_t(1) << GC_CHUNK_SHIFT;

So we have 1MB chunks and we hold on to them for 3 GCs.
I guess we still have the problem that we hold on to them (forever?) if there is no JavaScript activity. So if we don't move the mouse or click on something. 

This might change if I finish bug 656120 where I want to release the chunks right away for an "idle" GC.

Comment 4

[David Mandelin [:dmandelin]]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Currently we perform 67 GCs during the web-based v8 benchmark on my MBP.
> > > We use 487 Chunks (because of splay) and get a score of about 4870.
> > > 
> > > If we reduce the heap growth factor to 2.5 instead of 3 we perform 79 GCs.
> > > We use 407 Chunks and get a score of 4820.
> > > 
> > > Seems like we should take this regression in favor of the smaller footprint.
> > > I will look at other memory intensive applications. 
> > 
> > How big is a chunk again? And how long do we hold on to the extra 80 chunks?
> 
> const size_t GC_CHUNK_SHIFT = 20;
> const size_t GC_CHUNK_SIZE = size_t(1) << GC_CHUNK_SHIFT;
> 
> So we have 1MB chunks and we hold on to them for 3 GCs.
> I guess we still have the problem that we hold on to them (forever?) if
> there is no JavaScript activity. So if we don't move the mouse or click on
> something. 
> 
> This might change if I finish bug 656120 where I want to release the chunks
> right away for an "idle" GC.

That seems good. I wouldn't want to take a 1% regression for 80MB, especially when that 80MB should be very short duration.

Comment 5

[Gregor Wagner [:gwagner]]

I also tested it on my Netbook and it definitely makes a difference for the splay benchmark:

2.5 Growth rate
Score: 1098
Richards: 1844
DeltaBlue: 1140
Crypto: 1643
RayTrace: 821
EarleyBoyer: 1172
RegExp: 369
Splay: 1567

trunk:
Score: 1049
Richards: 1827
DeltaBlue: 1123
Crypto: 1661
RayTrace: 812
EarleyBoyer: 1143
RegExp: 371
Splay: 1190

Comment 6

[Nicholas Nethercote [inactive]]

Gregor, should we keep this bug open?  Doesn't look like it's going anywhere, and there's plenty of other GC work going on so I suspect the GC will be retuned anyway...

Comment 7

[Nicholas Nethercote [inactive]]

Closing as per comment 6.  Please reopen if you want.