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)
Firefox Build System
General
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)
5.23 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•15 years ago
|
Whiteboard: [ts]
Comment 1•15 years ago
|
||
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
Comment 2•15 years ago
|
||
Seems like the code would be ok with being switched to non-file urls.
Comment 3•15 years ago
|
||
Most non-file URIs don't support nsIHashable, you'd need fastload invalidation in mozJSComponentLoader::GlobalForLocation at least.
Reporter | ||
Updated•15 years ago
|
OS: Mac OS X → All
Priority: -- → P2
Hardware: x86 → All
Reporter | ||
Updated•15 years ago
|
Assignee: nobody → ddahl
Comment 4•15 years ago
|
||
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?
Comment 5•15 years ago
|
||
3 is the only hard part. The rest can be accomplished by putting these JS modules in jar.mn
Comment 6•15 years ago
|
||
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!)
Comment 8•15 years ago
|
||
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?
Comment 9•15 years ago
|
||
I think we should keep toolkit.jar and browser.jar separate, just as we do for chrome.
Comment 10•15 years ago
|
||
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?
Comment 11•15 years ago
|
||
Use the existing toolkit.jar and browser.jar... we'll have them open for chrome anyway.
Comment 12•15 years ago
|
||
(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.
Comment 13•15 years ago
|
||
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.
Updated•15 years ago
|
Attachment #399352 -
Flags: review? → review?(tglek)
Comment 15•15 years ago
|
||
(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
Comment 16•15 years ago
|
||
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)?
Comment 17•15 years ago
|
||
Yes, you need to make sure that fastload for these files still works.
Comment 18•15 years ago
|
||
If we are already fastloading these files, is it really worth it to also jar them up? Will this only affect cold start then?
Updated•15 years ago
|
Assignee: ddahl → nobody
Reporter | ||
Comment 19•15 years ago
|
||
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
Comment 20•14 years ago
|
||
Is this related to bug 406538 in some way?
Updated•14 years ago
|
Attachment #399352 -
Flags: review?(tglek)
Comment 21•14 years ago
|
||
Fixed by omnijar.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•