Bugzilla

I was looking at why Window objects of already run tests stayed in the CC graph for a long time. It seems that there is a JS List object which has references to those globals through baseshape_global edges. That List lives in the parent page. (Is it used internally for async iteration or what?)

From Matrix
jonco: ICs have GC pointers e.g. to shapes to guard against, and ideally these should really be weak pointers but at the moment they are not. My guess is that is where these are coming from

And jandem suggested trying with javascript.options.blinterp = false
With that I didn't see the all the time increasing GC times, but I did run sp3 with profiler just once with that pref.

Note, we do run almost all the GC/CC slices outside the measured time in sp3, almost. Especially closer to the end of the test one starts to see ALLOC_TRIGGER slices from JS engine happening during the measured time.

I was looking at why Window objects of already run tests stayed in the CC graph for a long time. It seems that there is a JS List object which has references to those globals through baseshape_global edges. That List lives in the parent page. (Is it used internally for async iteration or what?)
The List is apparently collected at the end of the test.

From Matrix
jonco: ICs have GC pointers e.g. to shapes to guard against, and ideally these should really be weak pointers but at the moment they are not. My guess is that is where these are coming from

And jandem suggested trying with javascript.options.blinterp = false
With that I didn't see the all the time increasing GC times, but I did run sp3 with profiler just once with that pref.

Note, we do run almost all the GC/CC slices outside the measured time in sp3, almost. Especially closer to the end of the test one starts to see ALLOC_TRIGGER slices from JS engine happening during the measured time.