1403336 - javascript.options.baselinejit doesn't disable baseline (prefs not yet loaded?)

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect, P3)

Description

[(Away)]

STR:
1. Toggle javascript.options.baselinejit to false
2. Restart Firefox under a debugger
3. Put a breakpoint on ReloadPrefsCallback [1]
4. Observe call to Preferences::GetBool(JS_OPTIONS_DOT_STR "baselinejit")

Expected result: It returns false
Actual result: It returns true

This prevents me from working around the JIT crashes in bug 1403317.

Stack when I hit the breakpoint:
00 xul!ReloadPrefsCallback
01 xul!XPCJSContext::Initialize
02 xul!XPCJSContext::NewXPCJSContext
03 xul!nsXPConnect::nsXPConnect
04 xul!nsXPConnect::InitStatics
05 xul!xpcModuleCtor
06 xul!Initialize
07 xul!nsComponentManagerImpl::KnownModule::Load
08 xul!nsFactoryEntry::GetFactory
09 xul!nsComponentManagerImpl::CreateInstanceByContractID
0a xul!nsComponentManagerImpl::GetServiceByContractID
0b xul!CallGetService
0c xul!nsGetServiceByContractID::operator()
0d xul!nsCOMPtr_base::assign_from_gs_contractid
0e xul!nsCOMPtr<nsISupports>::nsCOMPtr<nsISupports>
0f xul!NS_InitXPCOM2
10 xul!ScopedXPCOMStartup::Initialize
11 xul!XREMain::XRE_main
12 xul!XRE_main
13 firefox!do_main

[1] http://searchfox.org/mozilla-central/source/js/xpconnect/src/XPCJSContext.cpp#768

Comment 1

[Ted Campbell [:tcampbell]]

Do you have any advice for this (or who would know about pref loading)? It sounds like the same early pref problem as JSM global sharing pref had.

Comment 2

[Kris Maglione [:kmag]]

The first XPCJSContext is created early very early in the startup cycle, before we've read any preferences, so the initial values will always be the defaults, but they'll be updated as soon as we read user preferences, which should generally be before we've run any JS code. But I suppose self-hosted JS might still be a problem:

http://searchfox.org/mozilla-central/rev/f6dc0e40b51a37c34e1683865395e72e7fca592c/js/xpconnect/src/nsXPConnect.cpp#135-136

I did move user pref initialization to an earlier point in startup in bug 1398895, and we could theoretically move it earlier still. But the toolkit profile service is responsible for preference initialization, and this part of XPCOM doesn't know about the toolkit profile service (since it isn't used in places like the xpcshell), so that's easier said than done.

Where/when exactly is the value of this preference causing a problem?

Comment 3

[(Away)]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #2)
> Where/when exactly is the value of this preference causing a problem?

Flag on me to follow up and answer this.

Comment 4

[(Away)]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #2)
> I did move user pref initialization to an earlier point in startup in bug 1398895

In comment 0 I was testing version 56, which didn't have your fix, so it's quite possible that things are better now. I want to confirm that's the case and then we can resolve this bug, but right now bug 1405735 is getting in the way of my local testing.

Comment 5

[(Away)]

Microsoft fixed the bug that was prompting me to disable JIT, so I'm no longer interested in this pref.