1253425 - Talos xperf whitelist only catches certain files on PGO builds

Status: RESOLVED WONTFIX

(Testing :: Talos, defect)

Description

[:Felipe Gomes (needinfo for replies!)]

The front-end code is now shipping some features through "system add-ons", which is code shipped from the tree, but lives as a separate add-on and can be updated out-of-band when needed.  This code ends up being separated in a new file, {firefox}\\browser\\features\\new.xpi

The last two times a new xpi was created, regular talos runs didn't catch this new file, and only pgo runs did.  See bug 1223573 comment 43, and https://treeherder.mozilla.org/logviewer.html#?job_id=22964840&repo=mozilla-inbound

It's probably worth investigating why this happens. My guess is packaging differences between the two builds, but I dunno. It would be easier to guess if it was the other way around..

We could remove all (or some) files from the whitelist and do a non-pgo run to see if it doesn't catch anything, or just a subset..


(Tangentially, this is probably going to bite every time someone creates a new system addon.. but I'm not sure what to do about that.. it will hopefully be not that frequent, and if it gets caught on non-pgo too that will make it harder to confuse someone.)

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

:ted, could you offer some advice on how we might be able to best investigate this?  Maybe any tips on pgo debugging?

Comment 2

[(not currently active) Ted Mielczarek]

There's not any real tips to be had. The main difference with PGO builds is just that the compiler does more work to optimize based on the results of running the profiling scenario. The only thing I know of that we do differently in packaging is that we write a jar log file during the profiling run and then use that for packaging:
https://dxr.mozilla.org/mozilla-central/rev/2b5237c178ea02133a777396c24dd2b713f2b8ee/toolkit/mozapps/installer/packager.mk#51
https://dxr.mozilla.org/mozilla-central/rev/2b5237c178ea02133a777396c24dd2b713f2b8ee/toolkit/mozapps/installer/packager.py#381

I don't recall exactly how that all works, but I know we use it to sort the entries in omni.ja in order of access. If we're recording accesses to these new XPIs it may be that we do something different in packaging and they wind up getting preloaded?

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

closing out old bugs that haven't been a priority