Closed
Bug 128366
Opened 23 years ago
Closed 20 years ago
OJI causes plugin DLL to load at startup, scan for plugins, and load Java DLL's
Categories
(Core Graveyard :: Java: OJI, defect, P3)
Core Graveyard
Java: OJI
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8alpha6
People
(Reporter: peterlubczynski-bugs, Assigned: bryner)
References
Details
(Keywords: memory-footprint, perf, Whiteboard: [PL2:NA])
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
bryner
:
review+
shaver
:
superreview+
|
Details | Diff | Splinter Review |
To help see when plugin scanning first happens, run with this environment variable: NSPR_LOG_MODULES=Plugin:5 Notice that when Java is disabled in the prefs at startup, the initial plugin scan is delayed until plugins are actually needed. In fact, the host's constructor isn't even called. Delaying the scan from startup may be a performance win and save on some allocations. From briefly looking at it, it looks like the JVM Manager needs the Java plugin's factory. Here's the stack: nsPluginHostImpl::LoadPlugins(nsPluginHostImpl * const 0x00f201fc) li nsPluginHostImpl::GetPluginFactory(nsPluginHostImpl * const 0x00f201 nsJVMManager::StartupJVM() line 665 + 32 bytes nsJVMManager::MaybeStartupLiveConnect() line 901 + 20 bytes nsJVMManager::StartupLiveConnect(nsJVMManager * const 0x00f13ae nsJSEnvironment::Init() line 1682 + 34 bytes NS_CreateScriptContext(nsIScriptGlobalObject * 0x00f13158, nsIScriptC nsDOMSOFactory::NewScriptContext(nsDOMSOFactory * const 0x00f1 nsDocShell::EnsureScriptEnvironment(nsDocShell * const 0x00f1f990) li nsWebShell::GetInterface(nsWebShell * const 0x00f1f9b8, const nsID & nsGetInterface::operator()(const nsID & {...}, void * * 0x0012f6c8) line 5 nsCOMPtr<nsIDOMWindow>::assign_from_helper(const nsCOMPtr_he nsCOMPtr<nsIDOMWindow>::nsCOMPtr<nsIDOMWindow>(const nsC nsAppShellService::RegisterTopLevelWindow(nsAppShellService * con nsAppShellService::CreateTopLevelWindow(nsAppShellService * const nsWindowCreator::CreateChromeWindow(nsWindowCreator * const 0x0 nsWindowWatcher::OpenWindowJS(nsWindowWatcher * const 0x00f1c nsWindowWatcher::OpenWindow(nsWindowWatcher * const 0x00f1ce8 nsProfile::LoadDefaultProfileDir(nsCString & {...}, int 1) line 574 + 94 b nsProfile::StartupWithArgs(nsProfile * const 0x00f1d4c8, nsICmdLineSe nsAppShellService::DoProfileStartup(nsAppShellService * const 0x00f1a InitializeProfileService(nsICmdLineService * 0x00c42218) line 940 + 31 main1(int 1, char * * 0x00337ec0, nsISupports * 0x00000000) line 1242
Comment 1•23 years ago
|
||
Is this handled in the abstract LiveConnect Java <--> JavaScript API, which I thought was unaware of the browser embedding? Not sure, reassigning to Patrick as a possible LiveConnect bug; please reassign as necessary -
Assignee: rogerl → beard
Reporter | ||
Comment 2•23 years ago
|
||
From these numbers, it looks like caching plugin info in the application registry already does a pretty good job of improving startup time. Additional comments from Hong: The plugins installed were all standard (Java plugins, Shockwave Flash). On Windows there are a number of plugins like the Client Detection Tool and HP Printer Identifier which appear to be installed by the trunk installer. It did pick up the Shockwave Flash in the Communicator folder. On the Mac I noticed that Netscape was picking up Quicktime which was in the Apple system folder under "Internet plugins".
Reporter | ||
Comment 3•23 years ago
|
||
--->peterl Patrick is on sabatical. I looked at this over the weekend and I have a simple patch comming.
Reporter | ||
Comment 4•23 years ago
|
||
It appears that |StartupJVM| was being called at startup due to Liveconnect initilizing through |MaybeStartupLiveConnect|. |StartupJVM| would cause us to load plugins, scan (stat) them, and perhaps even load Java's DLLs. According to listdlls.exe, NPOJI610.dll, jpins32.dll, jpishare.dll, gkplugin.dll are being loaded at startup plus we always check timestamps of files in all plugins folders (application, user, and global). Since it works to install Java without restarting and also works to start with Java disabled and later enabled it in the prefs, the browser and the code supports calling |StartupJVM| later, whenever needed when |GetRunningJVM| is requested. This patch removes that call from |MaybeStartupLiveConnect| and the startup sequence and defers it to when Java is needed for the frist time. This also has the benefit of lazily loading plugins and not scanning until the first time actually needed in a browsing session. I've run through all the OJI Liveconnect tests here: http://www.mozilla.org/quality/browser/front-end/testcases/oji/liveconnecttest.html I have only run on Windows but they all pass like they do without the patch. Maybe only a little bit of time and memory would be gained at startup, but hopefully every little bit helps.
Comment 5•23 years ago
|
||
Since this turns out to involve OJI and not abstract LiveConnect, setting component to OJI. This answers the question in Comment #1.
Component: Live Connect → OJI
QA Contact: pschwartau → pmac
Updated•23 years ago
|
Priority: -- → P3
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.0.2
Reporter | ||
Updated•22 years ago
|
Comment 8•22 years ago
|
||
If we remove StartupJVM call, will JSJ_ConnectToJavaVM call still succeed? I remember some one add that code purposly to hack around liveconnect.
Comment 10•21 years ago
|
||
Comment on attachment 89788 [details] [diff] [review] patch to remove StartupJVM() call from nsJVMManager::MaybeStartupLiveConnect() 'r=?': (see comment 8) Who can test/answer your question ?
Attachment #89788 -
Flags: review?(xiaobin.lu)
Assignee | ||
Comment 11•20 years ago
|
||
Profiling and tinderbox tests show that this accounts for about half of startup time on OS X. (In reply to comment #8) > If we remove StartupJVM call, will JSJ_ConnectToJavaVM call still succeed? I > remember some one add that code purposly to hack around liveconnect. If a java_vm_arg is passed into JSJ_ConnectToJavaVM, it will call the attach_current_thread callback (attach_current_thread_impl), which calls JVM_GetJNIEnv(), which calls GetRunningJVM(), which will start the JVM if it is enabled but not yet started. So, I think this should be ok. I also tested on windows and found that all the tests pass (at least, the ones that passed before); I'll do some testing on other platforms as well.
Assignee: peterl-bugs → bryner
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla1.8alpha6
Assignee | ||
Comment 12•20 years ago
|
||
Comment on attachment 89788 [details] [diff] [review] patch to remove StartupJVM() call from nsJVMManager::MaybeStartupLiveConnect() r=bryner. I tested on Windows and Linux and found that liveconnect tests passed both with and without the patch. On Mac, Liveconnect doesn't seem to work even without this patch, so I don't think it's going to regress anything.
Attachment #89788 -
Flags: superreview?(shaver)
Attachment #89788 -
Flags: review?(xiaobin.lu)
Attachment #89788 -
Flags: review+
Comment on attachment 89788 [details] [diff] [review] patch to remove StartupJVM() call from nsJVMManager::MaybeStartupLiveConnect() Awesome. sr=shaver. (though, really, do we need to keep the #if 0 section? we have CVS)
Attachment #89788 -
Flags: superreview?(shaver) → superreview+
Comment 14•20 years ago
|
||
before changing mac java support, could we *please* cc the mrj plugin replacement (jep)?
Comment 15•20 years ago
|
||
Is there a Mac OS X binary which contains the changes discussed here, that I can test against (a nightly or something similar)? I'm the author of something called the Java Embedding Plugin, which allows other web browsers than Safari to use Java 1.4.X on OS X. http://javaplugin.sourceforge.net/ (By the way, the Java Embedding Plugin (via the "MRJ Plugin JEP") currently already starts the 1.4.X JVM as the browser is being launched. The main reason I did this is to be able to support LiveConnect when used outside of any applet -- as most of the Mozilla "OJI test cases" require.) http://www.mozilla.org/quality/browser/front-end/testcases/oji/liveconnecttest.html
Assignee | ||
Comment 17•20 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 18•20 years ago
|
||
> checked in
I suppose this means a binary has (or will be) generated. Where do I
look for it?
Comment 19•20 years ago
|
||
> > checked in > > I suppose this means a binary has been (or will be) generated. > Where do I look for it? Well? I notice that the "Target Milestone" (above) is "mozilla1.8alpha6". Does that mean that Mozilla 1.8a6, when it comes out, will contain this patch?
Comment 20•20 years ago
|
||
(In reply to comment #19) > > > checked in > > > > I suppose this means a binary has been (or will be) generated. > > Where do I look for it? All nighlies since the checkin should include it. Learn more there: <http://www.mozilla.org/developer/>.
Comment 21•20 years ago
|
||
This patch probably exacerbated bug 273785 a good bit for people who have Java enabled...
Comment 22•20 years ago
|
||
Steven, have you tested your plugin with a recent nightly/1.8a6? 1.8a6 (with this patch) worked/s for me and I added the release notes of 1.8a6 that your plugin needs to be installed. (http://www.mozilla.org/releases/mozilla1.8a6/installation-extras.html#extras_java)
Comment 23•20 years ago
|
||
Yes I did. It works fine (and it should generally now work with even the latest Mozilla, Camino and Firefox nightlies). I made changes in JEP 0.8.9 that specifically address the changes that were made here. Here's item #1 in that version's Changes.txt: > 1. Changed back to launching the version 1.4.X Java Virtual Machine on > demand (whenever Java is used for the first time in a browser > session). > > From versions 0.8.3 to 0.8.8, the Java Embedding Plugin launched > the 1.4.X JVM as the browser started up. The change was made to > accomodate using LiveConnect outside of any applet. I've now > figured out how to do this without launching the JVM at browser > startup (for more information see maybeCreateJavaVM and > loadAWTLibraries in AppletView.m). > > Furthermore, future releases of the Mozilla-family browsers will no > longer be able to launch the JVM at startup (because they will no > longer load the MRJ Plugin at startup). This change has already > appeared in the nightlies created since 12-02-2004 (except for > those corresponding to the "1.7 branch"). For more information on > this change see: > > https://bugzilla.mozilla.org/show_bug.cgi?id=128366
You need to log in
before you can comment on or make changes to this bug.
Description
•