Closed Bug 437002 Opened 12 years ago Closed 10 years ago

win32 mozilla-central weirdness with PGO

Categories

(Release Engineering :: General, defect, P2, major)

x86
Windows XP

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: vlad, Assigned: ted)

References

(Blocks 1 open bug)

Details

The win32 m-c builder reports a pile of lines like:

e:\builds\moz2-slave\mozilla-central-win32\build\netwerk\protocol\file\src\nsfilechannel.cpp(70) : warning C4952: 'nsFileCopyEvent::Status' : no profile data found in program database 'xul.pgd'
e:\builds\moz2-slave\mozilla-central-win32\build\netwerk\protocol\file\src\nsFileChannel.cpp : warning C4952: 'nsCOMPtr<nsIInputStreamCallback>::~nsCOMPtr<nsIInputStreamCallback>' : no profile data found in program database 'xul.pgd'
e:\builds\moz2-slave\mozilla-central-win32\build\netwerk\base\src\nsbasecontentstream.h(105) : warning C4952: 'nsBaseContentStream::OnCallbackPending' : no profile data found in program database 'xul.pgd'

These don't appear in the Firefox 3 builder's line; they're all followed by:

68263 of 80242 functions (85.1%) were optimized using profile data
425121811 of 591452373 instructions (71.9%) were optimized using profile data
 or variants thereof.

However, on the trunk, this tends to look more like:

PGOMGR : warning PG0188: No .PGC files matching 'xul!*.pgc' were found.
   Creating library xul.lib and object xul.exp
Generating code
2402 of 80617 (  2.98%) profiled functions will be compiled for speed
80617 of 82890 functions (97.3%) were optimized using profile data
568947940 of 591984713 instructions (96.1%) were optimized using profile data
Finished generating code
chmod +x xul.dll

The percentages are significantly higher; are the m-c machines faster, maybe?

Also, sometimes this seems to cause

LINK : fatal error LNK1257: code generation failed

I'm going to guess because:

e:\builds\moz2-slave\mozilla-central-win32\build\netwerk\cookie\src\nscookie.cpp(144) : error C2220: warning treated as error - no 'executable' file generated
e:\builds\moz2-slave\mozilla-central-win32\build\netwerk\cookie\src\nscookie.cpp(144) : warning C4952: 'nsCookie::GetPolicy' : no profile data found in program database 'xul.pgd'
e:\builds\moz2-slave\mozilla-central-win32\build\netwerk\cookie\src\nscookie.cpp(143) : warning C4952: 'nsCookie::GetStatus' : no profile data found in program database 'xul.pgd'

cookies is the only thing in the tree that builds with WARNINGS_AS_ERRORS by default; I'm going to disable it in hopes of fixing the red.
These machines are very very similar to the Firefox 3 ones. Their core OS/compiler/etc is identical, and only certain tools differ.

Could this maybe happen if the profiling script doesn't launch Firefox correctly? I don't think this would be the case since debug+leak tests are running fine...just a guess though.
Hm, we specifically add some warning disable flags to account for that warnings_as_errors stuff:
http://mxr.mozilla.org/mozilla-central/source/configure.in#1977

It definitely looks like we're getting less coverage from the profiling for some reason.
(In reply to comment #0)
[snip]
> The percentages are significantly higher; are the m-c machines faster, maybe?

Nope, these mozilla-central VMs are identical clones of the VMs that are running on cvs-trunk for Firefox3. Not sure if the VMs are running on the same ESXhosts, but that should not matter this much.


(In reply to comment #2)
> Hm, we specifically add some warning disable flags to account for that
> warnings_as_errors stuff:
> http://mxr.mozilla.org/mozilla-central/source/configure.in#1977

Is there any way these extra flags could be causing this difference?
No, those flags were added on CVS trunk.
fyi, nsCookie::GetPolicy and ::GetStatus have no callers, they're legacy interface methods. i assume the compiler is warning because they're not showing up in the profile data, which seems a bit picky...
Yeah, and it appears to honor the warnings-as-errors stuff for that warning, which is ridiculous. This is why we added those -wd flags, which seemed to let us work around them, although apparently not consistently.
Taking for investigation.
Assignee: nobody → ted.mielczarek
Priority: -- → P2
Lots have changed in the almost 2 years since last comment. Is this still an issue or can we close this?
Yeah, clearly we're not seeing this anymore.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Product: mozilla.org → Release Engineering
Blocks: 1416285
You need to log in before you can comment on or make changes to this bug.