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.

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

(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?

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

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

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

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

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