437002 - win32 mozilla-central weirdness with PGO

Status: RESOLVED WORKSFORME

(Release Engineering :: General, defect, P2)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 1

[[e-mail] (:bhearsum)]

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.

Comment 2

[(not currently active) Ted Mielczarek]

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.

Comment 3

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

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

Comment 4

[(not currently active) Ted Mielczarek]

No, those flags were added on CVS trunk.

Comment 5

[[e-mail]]

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

Comment 6

[(not currently active) Ted Mielczarek]

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.

Comment 7

[(not currently active) Ted Mielczarek]

Taking for investigation.

Comment 8

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Lots have changed in the almost 2 years since last comment. Is this still an issue or can we close this?

Comment 9

[(not currently active) Ted Mielczarek]

Yeah, clearly we're not seeing this anymore.