768325 - Need to be able to access libxul functions from gkmedia on windows for webrtc

Status: RESOLVED DUPLICATE of bug 699646

(Firefox Build System :: General, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

Attachment: IRC discussion with jesup, ekr, glandium, ted, etc

We need to be able to access XPCOM/network/etc functions in liubxul from gkmedia on Windows, which is not currently possible.

Suggestions from glandium and ted (ehsan was in agreement after the fact):

1) Try linking gkmedia as a static library with libxul with full PGO (now that we're on 64-bit windows builders) and see what the max memory usage is (with webrtc and signaling enabled, which would mean (currently) alder/default)

2) Try linking gkmedia as a static non-PGO library with xul and measure memory use.  (I.e. add -Gy- by defining NO_PROFILE_GUIDED_OPTIMIZE=1)

3) Try moving media/webrtc/signaling (and probably ekr's transport code) to xul, leaving the rest of webrtc in gkmedia as current, and add a ton of C++ symbols to symbols.def.in (or find some more automatic way to do so).  This is a bit of a maintenance nightmare due to having to track API changes and likely to be fragile (and may involve quite a few hacks along the way).

I'll attach an IRC log with a bunch of details

First step is to measure the memory use for cases #1 and #2.

My initial try build using glandium's simple patch died with a bunch of unknown symbols (could be symbols.def.in biting us; I didn't debug - try build was triggered late Wednesday night/thurs morning EDT IIRC)

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Merge gkmedia in with XUL on windows

Comment 2

[Mike Hommey [:glandium]]

Comment on attachment 636733 [details] [diff] [review]
Merge gkmedia in with XUL on windows

Review of attachment 636733 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/library/Makefile.in
@@ +547,5 @@
> +ifdef MOZ_WEBRTC
> +EXTRA_DSO_LDOPTS += \
> +  -LIBPATH:"$(MOZ_DIRECTX_SDK_PATH)/lib/$(MOZ_DIRECTX_SDK_CPU_SUFFIX)" \
> +  $(NULL)
> +OS_LIBS += $(call EXPAND_LIBNAME,secur32 crypt32 iphlpapi strmiids dmoguids wmcodecdspuuid amstrmid msdmo wininet)

You're missing this:
ifdef MOZ_CUBEB
OS_LIBS += $(call EXPAND_LIBNAME, winmm)
endif

Note that if this works, you'll want to remove the parts you commented out, and also all EXTRA_DSO_LDOPTS and OS_LIBS in layout/media/Makefile.in.

Comment 3

[Mike Hommey [:glandium]]

Actually, if we go this way, we can just get rid of layout/media/Makefile.in and move things back in toolkit/library/Makefile.in.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

https://tbpl.mozilla.org/?tree=Try&rev=0b3cc46f7b5d

re: MOZ_CUBEB - right.  I was mostly trying to get it to work and get the rough PGO memory reading; this isn't a review-ready patch.

Comment 5

[Mike Hommey [:glandium]]

(In reply to Randell Jesup [:jesup] from comment #4)
> https://tbpl.mozilla.org/?tree=Try&rev=0b3cc46f7b5d
> 
> re: MOZ_CUBEB - right.  I was mostly trying to get it to work and get the
> rough PGO memory reading; this isn't a review-ready patch.

I know, I'm just saying, because MOZ_CUBEB is enabled by default.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Merge gkmedia with XUL on windows (2)

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

https://tbpl.mozilla.org/?tree=Try&rev=1bb694191ec7

Win x32:   
linker max vsize: 3830517760
check: 19965/0

Win x64:
linker max vsize: 3811520512
check: 19980/0

This would give us somewhere less than 464,xxx,xxx bytes (442MB), depending on how much of the 4GB address space is actually usable.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 768325: Merge gkmedia with XUL on windows (3)

Patch used in try (basically) -- against alder/default

Comment 9

[Mike Hommey [:glandium]]

(In reply to Randell Jesup [:jesup] from comment #7)
> https://tbpl.mozilla.org/?tree=Try&rev=1bb694191ec7
> 
> Win x32:   
> linker max vsize: 3830517760
> check: 19965/0
> 
> Win x64:
> linker max vsize: 3811520512
> check: 19980/0
> 
> This would give us somewhere less than 464,xxx,xxx bytes (442MB), depending
> on how much of the 4GB address space is actually usable.

How much is the linker max vsize with the same code, but with gkmedias separated?

Comment 10

[(not currently active) Ted Mielczarek]

That doesn't seem like it gives us a lot of breathing room, especially considering that we have no recourse when we hit the 4GB limit.

Comment 11

[Mike Hommey [:glandium]]

(In reply to Ted Mielczarek [:ted] from comment #10)
> That doesn't seem like it gives us a lot of breathing room, especially
> considering that we have no recourse when we hit the 4GB limit.

Let's see how it goes with webrtc not PGOed.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

For reference, a recent Win x32 PGO build on m-c:  
linker max vsize: 3166093312
check: 23285/0

Increase for including all of gkmedia and media/webrtc (which includes ~750K lines of code, plus an additional ~500K lines of code  on alder that mostly will not land on m-c!) is ~670MB

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Merge gkmedia with XUL on windows (against m-c)

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

Attachment: config changes to test PGO memory use on Windows

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Merge gkmedia with XUL on windows (alder)

Comment 16

[(not currently active) Ted Mielczarek]

Just going to fix this over in bug 699646.