Closed Bug 509755 Opened 15 years ago Closed 14 years ago

js modules should be packaged into a jar file

Categories

(Firefox Build System :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 556644

People

(Reporter: dietrich, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [ts])

Attachments

(1 file)

we can take advantage of bug 504864 by putting the modules directory into a jar, and have Components.utils.import() load from there in a way that is transparent to callers.
Whiteboard: [ts]
FWIW that involves some significant changes to the xpconnect Cu.import code, which currently reads the data from a file:

http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/loader/mozJSComponentLoader.cpp#1543
Seems like the code would be ok with being switched to non-file urls.
Most non-file URIs don't support nsIHashable, you'd need fastload invalidation in mozJSComponentLoader::GlobalForLocation at least.
Blocks: 459117
OS: Mac OS X → All
Priority: -- → P2
Hardware: x86 → All
Depends on: 508421
Assignee: nobody → ddahl
Please forgive my ignorance, I think this will require:

1. Identify each js module file path that we want to bundle into this jar.
1b. Identify where this .jar should reside in the build.
2. Create a jar manifest file listing each path, etc.
2b. Add build steps to actually build the .jar
3. Alter mozJSComponentLoader so that it can consume either a jar: URI or overload the method so that it can accept the module code as a string as well as a file URI?
3 is the only hard part. The rest can be accomplished by putting these JS modules in jar.mn
added this WIN32_REDIST_DIR=$VCINSTALLDIR\redist\x86\Microsoft.VC80.CRT to my moxconfig as rs and I thought it was a crt issue. Maybe it is.

Still crashes when running nss/shlibsign -v -i objdir/dist/lib/softokn3.dll

Should I downgrade to vs 2007? 2005? Vista? (NO!)
sorry - comment 6 was for another bug.
According to this MXR query: http://mxr.mozilla.org/mozilla-central/search?string=EXPORTED_SYMBOLS&case=on&find=\.js&findi=\.js&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

These are all of the js modules in the tree:

netwerk/base/src/NetUtil.jsm
js/src/xpconnect/loader/XPCOMUtils.jsm
js/src/xpconnect/loader/ISO8601DateUtils.jsm
intl/locale/src/PluralForm.jsm
toolkit/components/places/src/utils.js
toolkit/components/places/src/PlacesDBUtils.jsm
toolkit/components/microformats/src/Microformats.js
toolkit/mozapps/downloads/src/DownloadUtils.jsm
toolkit/mozapps/downloads/src/DownloadLastDir.jsm
toolkit/mozapps/extensions/src/LightweightThemeManager.jsm
toolkit/spatial-navigation/SpatialNavigation.js
toolkit/content/debug.js
toolkit/content/WindowDraggingUtils.jsm
browser/components/distribution.js
browser/base/content/openLocationLastURL.jsm

So we want all of these file packaged in one jar, correct?
I think we should keep toolkit.jar and browser.jar separate, just as we do for chrome.
Do we want the modules to reside in the build in dist/bin/modules/browser.jar and dist/bin/modules/toolkit.jar.

As of now, the modules dir has all these modules except LightweightThemeManager.jsm, which I assume is only landed on trunk?

Should all of the modules from toolkit be in toolkit.jar and the rest in browser.jar, even if they do not come from browser?

Will this be less of a perf win with 2 jars? All of these files are in this location when distributed, won't it not matter that they are all in one jar?
Use the existing toolkit.jar and browser.jar... we'll have them open for chrome anyway.
(In reply to comment #10)
> Should all of the modules from toolkit be in toolkit.jar and the rest in
> browser.jar, even if they do not come from browser?

The ones that come from non-browser locations should typically be in toolkit.jar as that is the core .jar that is shared across apps. All browser specific items should be in browser.jar - only firefox has that version.
Blocks: 513027
Is this file ( toolkit/mozapps/downloads/src/DownloadUtils.jsm ) already packaged somewhere else? it is in the source dir, but is not in the obj dir, and my attempts at packaging it have failed:

  File "/home/ddahl/code/moz/mozilla-central/mozilla/config/JarMaker.py", line 378, in _processEntryLine
    raise RuntimeError("file not found: " + src)
RuntimeError: file not found: downloads/content/src/DownloadLastDir.jsm

I added this line to toolkit/mozapps/jar.mn:

  content/mozapps/downloads/DownloadUtils.jsm                   (downloads/content/src/DownloadUtils.jsm)

Another file, "DownloadLastDir.jsm", in the same dir worked fine.
Attached patch jar.mn additionsSplinter Review
Am I on the right track here?
Attachment #399352 - Flags: review?
Attachment #399352 - Flags: review? → review?(tglek)
(In reply to comment #14)
> Created an attachment (id=399352) [details]
> jar.mn additions
> 
> Am I on the right track here?

i think so, i'm not sure what xpcnativewrappers= stuff does
I noticed this comment in GlobalForLocation:

http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/loader/mozJSComponentLoader.cpp#1192

1192     // Before compiling the script, first check to see if we have it in
1193     // the fastload file.  Note: as a rule, fastload errors are not fatal
1194     // to loading the script, since we can always slow-load.

Will the files we want jarred up be fast loaded as well? How will this affect the bug? will we need to also update the function that does the fastload check (do_GetFastLoadService)?
Yes, you need to make sure that fastload for these files still works.
If we are already fastloading these files, is it really worth it to also jar them up? Will this only affect cold start then?
Assignee: ddahl → nobody
extension installation triggers component re-registration, which afaict *does* trigger fastload cache invalidation. if this is the case, we do still want to fix this, since fear-of-dog-slow-restart is big problem wrt to encouraging people to use extensions.

however, the cache-invalidated-restart scenario is lower priority than optimizing typical warm/cold startup.
Priority: P2 → P3
Blocks: 517569
No longer blocks: 517569
Blocks: 447581
Is this related to bug 406538 in some way?
Attachment #399352 - Flags: review?(tglek)
Fixed by omnijar.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.