478255 - Create a static xulrunner configuration

Status: RESOLVED INCOMPLETE

(Toolkit Graveyard :: XULRunner, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

Due to some memory management and DLL loading issues on Windows Mobile (wince 5), we may get better startup performance and memory handling if we take XUL.DLL out of the game and statically link it to XULRUNNER.EXE

I don't want to throw away the ability to run other XUL-based apps, so I am not suggesting we create a statically linked FENNEC.EXE

The Fennec stub currently spawns XULRUNNER.EXE anyway, so this would not be a big change for the front-end application.

Comment 1

[Brian Crowder]

Based on discussions on IRC, it seems like what we really want here is a tiny xulrunner.exe and a large dll that incorporates xul.dll, nss.dll, nspr.dll, js.dll and so on all together.

Comment 2

[Benjamin Smedberg]

Really? The links I was given say that any kind of DLL will eat address space from all apps on the system, and it really has to be an executable.

Comment 3

[(not currently active) Ted Mielczarek]

There's different behavior between Windows CE 5.0 (which is used in Windows Mobile 6.0), and Windows CE 6.0 (which is used in Windows Mobile 6.1, IIRC)

CE 5.0 makes each DLL load eat VM from all other processes.
CE 6.0 loads DLLs in the large address space, outside of the processes' normal VM (IIRC).

Comment 4

[Benjamin Smedberg]

Which are we targeting (now and future)?

And is this request still needed for memory reasons, or is it needed for different performance reasons?

Comment 5

[Brian Crowder]

Windows Mobile 6.1 and better is the current target, and most hardware issued in the last few months is running it, so I think it's a legitimate target for now.  This won't really -hurt- us on older windows mobile, either.

One motivating factor here is that DLL loads are aligned on 64K boundaries.  For smaller DLLs, this means that we could be wasting a pretty decent chunk of memory.

My guess is we may also benefit in terms of overall startup time by having one monolithic DLL as opposed to several, but I haven't benchmarked to prove it.

Comment 6

[Benjamin Smedberg]

Do small DLLs spend memory or just address space aligning on 64k?

Moving NSPR into libxul isn't that hard by itself... NSPR already has static libs. JS probably also isn't that hard. What is extremely difficult is NSS, which has NSPR dependencies. I'd really hate to have someone go through the pain of creating a static NSS (it involves significant code changes, not just build system changes) unless we're sure it's going to provide a noticeable benefit.

Comment 7

[(not currently active) Ted Mielczarek]

(In reply to comment #3)
> There's different behavior between Windows CE 5.0 (which is used in Windows
> Mobile 6.0), and Windows CE 6.0 (which is used in Windows Mobile 6.1, IIRC)

I was wrong here. Windows Mobile 6.1 and 6.5 are still based on Windows CE 5.0. There is no version of Windows Mobile currently shipping that's based on Windows CE 6.0. (I don't know what behavior WM6.1 and 6.5 exhibit.)

Comment 8

[Benjamin Smedberg]

XULRunner has been removed from the Mozilla tree: see https://groups.google.com/forum/#!topic/mozilla.dev.platform/_rFMunG2Bgw for context.

I am closing all the bugs currently in the XULRunner bugzilla component, in preparation for moving this component to the graveyard. If this bug is still valid in a XULRunner-less world, it will need to be moved to a different bugzilla component to be reopened.