604831 - TM: GC heuristic doesn't work after bug 602534

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gregor Wagner [:gwagner]]

Before the patch I get following allocation scheme:
    AppTime,  Total,   Mark,  Sweep, FinObj, FinStr,  Destroy,  newChunks, destroyChunks
         0.0,    6.7,    3.8,    2.2,    1.1,    0.3,      0.8,          2,          0
     18261.8,  192.7,  155.7,   27.5,   17.7,    0.9,      9.0,         92,          0
     19244.1,  460.1,  414.8,   41.8,   38.2,    0.4,      3.1,        185,          0
     22693.8,  932.5,  664.2,  264.6,  260.9,    0.4,      3.4,        557,          0
     29830.4, 1110.6,  615.6,  491.4,  487.4,    0.4,      3.5,        484,          0
     41789.0, 1073.7,  584.2,  485.8,  481.8,    0.4,      3.5,          0,          0
     51499.6, 1108.4,  599.4,  505.0,  501.1,    0.5,      3.5,          0,          0
     54004.1,  735.9,  591.4,  140.9,  137.2,    0.4,      3.3,          0,          0


Afterwards: 
     AppTime,  Total,   Mark,  Sweep, FinObj, FinStr,  Destroy,  newChunks, destroyChunks
         0.0,   18.7,   11.7,    4.7,    2.2,    0.3,      2.3,          3,          0
     32112.1,  190.2,  154.7,   27.1,   19.6,    1.1,      6.3,         90,          0
     40406.2, 1364.4,  731.7,  628.9,  624.7,    0.5,      3.7,       1376,          0
     53169.0, 1283.8,  636.4,  643.4,  638.8,    0.5,      4.1,         80,          0
     54453.2,  749.5,  680.7,   65.0,   60.9,    0.4,      3.7,          0,          0
     91490.8, 2020.4,  195.9, 1814.2, 1805.7,    0.5,      8.0,       1650,          0


We allocate 1376 chunks without a single GC.

Comment 1

[Gregor Wagner [:gwagner]]

The numbers are for:
http://29a.ch/2010/6/2/realtime-raytracing-in-javascript

Comment 2

[Gregor Wagner [:gwagner]]

Igor do you want to take a look why we allocate 1370 chunks at the beginning without performing a single GC run after the patch for 602534? 
We should fix this before we land other GC changes.

Comment 3

[Igor Bukanov]

(In reply to comment #2)
> Igor do you want to take a look why we allocate 1370 chunks at the beginning
> without performing a single GC run after the patch for 602534? 

I forgot to update dom/base/nsJSEnvironment.cpp to set the default trigger factor to 3, not 16.

Comment 4

[Igor Bukanov]

Attachment: v1

fixing the trigger number

Comment 5

[Gregor Wagner [:gwagner]]

Have you tested the link? I still get the same behavior with this patch. I will try a clean browser build now.

Comment 6

[Gregor Wagner [:gwagner]]

No, I still see the same behavior with this patch. We allocate 1300 chunks without a single GC and the memory usage goes up to 4GB for this benchmark.

Comment 7

[Igor Bukanov]

(In reply to comment #5)
> Have you tested the link?

No - will recheck tomorrow.

Comment 8

[Igor Bukanov]

There is one place that still keeps the old value of javascript.options.mem.gc_frequency callback as http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#600 also specifies it.

I will fix it and then check the link.

Comment 9

[Igor Bukanov]

Attachment: v2

With this patch for the benchmark above the GC happens when the heap size reaches 1.3 GB.

Comment 10

[Igor Bukanov]

http://hg.mozilla.org/tracemonkey/rev/449fea695930

Comment 11

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/449fea695930

Comment 12

[Gregor Wagner [:gwagner]]

I didn't have enough time to look at the browser benchmarks yesterday but today I see that this fix definitely changes the GC behavior and we perform more GC runs for the v8 benchmarks. 
For starting the browser and running the browser I see about 30% more GC runs.