mozilla :: #jsapi

19 Apr 2017
00:02ptomato-Msfink: RyanVM: I've tried out compiling a mozjs-52 tarball downloaded from treeherder. first obstacle is that the generated tarball doesn't include a configure script
00:03ptomato-MI can just create one by copying js/src/configure.in to js/src/configure since it now doesn't use any autoconf macros, right?
00:04ptomato-Mand if so, is there a way to get the configure script included in the tarball?
00:24shumccr8: ping
00:24hergertmedoes mozjs support any sort of dumping of the compiler state? say if i wanted to precompile some code and then restore from that to execute later?
00:25shuhergertme: we have a facility to serialize and deserialize our internal bytecode format, that's it
00:27hergertmeshu, happen to have a function name/etc i could use to find some code/docs?
00:29shuhergertme: docs are scant, unfortunately,
00:29shuhergertme: here's an entry point you can start poking around in http://searchfox.org/mozilla-central/source/js/src/jsapi.cpp#6935
00:30hergertmeshu, that will do just fine, thanks!
00:30shuhergertme: NB that this is not jit code, just bytecode
00:31hergertmeshu, i think that is fine. i mostly want to just get an idea of what our startup time is for JS based apps/shell in GNOME and what percentage is what.
00:32shuhergertme: ah, cool
00:32hergertmewhich means, i also need to forward port my mozjs profiler stuff to new mozjs ...
00:32shuhergertme: we were just talking about a startup image thing a la emacs yesterday
00:32shuhergertme: though i doubt we'll implement that anytime soon
00:34hergertmeyeah, it's a trade-off. we did it AOT in Mono years ago and just drop the jit in favor of startup perf in that case
00:34hergertmewell, and running on iOS
00:34hergertme^WX and all
00:34shuhergertme: neato
01:25shuis inbound open
01:25mrgigglesshu: mozilla-inbound: open
07:56jzkguys i just realized that every freakin line of js i've just written starts with "this."
07:56jzkwhat can i do about this
13:02h4writernbp: ping
13:02nbph4writer: pong
15:04lthluke: : eta on the wasm::Runtime thing?
15:07lukelth: should be end of day
15:07lthluke: awesome
15:45djvjsfink: uh, are we having GC meeting now?
15:45djvjjust saw jonco drop off IRC
15:45djvjsstangl: ^- ?
15:45sfinkI was just getting on
15:46sstanglyeah, logging in
15:48sstanglwindows update
15:59crowbotjdm: avadacatavra said that i'd forgotten to pass a destroy function to jsprincipal :)
16:02djvjhttps://searchfox.org/mozilla-central/source/dom/base/nsJSEnvironment.cpp#1216
16:11djvjhttps://bugzilla.mozilla.org/showdependencytree.cgi?id=1351769&hide_resolved=1
16:13sfinkhttp://searchfox.org/mozilla-central/source/js/src/jsgc.cpp#5955
16:17sfinkhttp://searchfox.org/mozilla-central/source/js/src/jsgc.cpp#6218
16:23djvjhttps://pastebin.mozilla.org/9019448
16:25djvjhttps://pastebin.mozilla.org/9019449
16:29sfinkfwiw, the triggering code we're talking about here is GCRuntime::maybeAllocTriggerZoneGC
16:32nbpdjvj: back on the JS engine?
16:40mrgigglesthe mozilla-inbound tree is now closed (reftest failures on linux asan)
16:46djvjnbp: what gave it away?
16:46nbpdjvj: the gdoc from the JS team meeting, and you asking jon about the GC meeting.
16:47nbpdjvj: and me not following anything for 2 weeks.
16:49nbpjzk: with(this) { } ? :just kidding:
16:50mrgigglesthe mozilla-inbound tree is now open
17:34jimbh4writer: ping
17:34h4writerjimb: pong
17:34jimbh4writer: Hi!
17:34jimbh4writer: I have more random TraceLogger threading questions.
17:34h4writerjimb: sure
17:34jimbh4writer: Which threads are allowed to call js::TraceLogEnableTextId? It seems like access to the TraceLoggerThreadState itself is unsynchronized. Is there only a single thread which is allowed to call that?
17:36h4writerjimb: in most cases they are called before executing
17:37h4writerjimb: there is a possibility to call this using "JS" in which case it works if there is only one mainthread. With multiple mainthreads there might be some delays and sync issues
17:37jimbh4writer: Okay, like via the Debugger API
17:38h4writerjimb: the big issue here is that when enabling "Engine" or "Script" label the IonScripts/BaselineScripts need to get "invalidated"
17:38h4writerjimb: which currently only happen on the thread that called the "enable/disable" call
17:38jimbright, I had some questions about that tooo
17:38jimbh4writer: Has anyone tried to use TraceLogger in the browser, or is it mostly a shell thing?
17:38jimbh4writer: Do you know of any reasons TraceLogger could not be used in the browser?
17:38h4writerjimb: toggling is mostly a shell thing currently
17:39h4writerjimb: tracelogger itself has been used in the browser
17:39jimbokay, xlnt
17:39jimbAs you mentioned, TraceLoggerThreadState::enableTextId calls ReleaseAllJITCode on a particular cx, but then adjusts settings in the process-wide TraceLoggerThreadState instance.
17:39h4writerjimb: indeed
17:39jimbSo in cases where you have multiple runtimes, the other threads probably won't notice until JIT code gets tossed for some other reason.
17:40h4writerjimb: there is one issue with e10s though, since they kill the process instead of actually call the deconstructors which write the data..
17:40h4writerjimb: correct
17:40jimbh4writer: oh, interesting
17:40jimbh4writer: so you never get the chance to flush your buffer
17:40h4writerindeed
17:41jimbh4writer: Would it make sense to make TraceLoggerThreadState associated with a particular runtime?
17:42jimbh4writer: Things like TraceLoggerThread::startEvent would need to take an rt or cx argument...
17:42h4writerjimb: might be the better way (at the time I didn't want how SM worked dictate how TL is implemented)
17:42nbpjimb: We still have a JSRuntime in the child process, and we do not call the JSRuntime destructor.
17:43h4writeralso related to my ignorance about JSRuntime/Compartment/JSContext knowledge
17:43h4writernbp: I think he is referring to the sync issues. Not the deconstructor issues.
17:43nbph4writer: could we have "flush"-points?
17:44h4writernbp: we can flush anytime. Currently we do it if we run out of storage
17:44jimbnbp: Yes, for the moment I'd like to concentrate on the multi-runtime and threading questions.
17:45jimbh4writer: I certainly understand wanting to keep TL not intertwined with SM.
17:45jimbh4writer: I think that could be accomplished.
17:46jimbh4writer: I'm not sure if I'm blocked, per se, on solving this, but I am always blocked on not crashing all over the place
17:46h4writerjimb: hehe yes indeed
17:46jimbh4writer: But if there were a patch that make TL per-Runtime without filling it with cx and rt pointers everywhere, you'd be sympathetic?
17:47h4writerjimb: yes
17:47jimbh4writer: xlnt, thanks!
17:48h4writerjimb: thinking about it, I might have a fix for the e10s issue too.
17:48jimbokay!
17:48h4writerjimb: I had bug 1298831 and know why it didn't work, but just realized how to do it properly
17:48firebothttps://bugzil.la/1298831 NEW, hv1989@gmail.com Get tracelogger working in E10S opt build
17:49jimbI see.
17:49h4writerI'll create that Friday
17:55nbpmrbkap: Could I just spell out Sync as Synchronize instead of finding other wording, because of the rest of the functions which also have Sync in their names?
17:55nbpmrbkap: ^ for Bug 900784 part 1.0
17:56firebothttps://bugzil.la/900784 ASSIGNED, nicolas.b.pierron@mozilla.com [meta] Add start-up cache for any JavaScript code.
17:56mrbkapnbp: Yeah, that's fine.
17:59nbpmrbkap: I honestly did not expected so many r+ on the first shot for review. I heard about a place where people give a ton of r- all the time instead of cancelling the reviews. :)
17:59jimbjorendorff: Can you think of any way for a random thread to ask a JSRuntime's main thread to do some operation for it?
18:00jimblike the way Gecko lets you stick runnables on a thread's event queue
18:00jimbOr has SpiderMonkey managed to escape needing to do anything like that?
18:00mrbkapnbp: Reading through the bug it seemed like I'm not the first reviewer anyway.
18:00nbpjimb: Do we have an event queue for promises yet?
18:00jorendorffjimb: going into a meeting right now
18:00nbpjimb: we have the interrupt callback.
18:00jimbjorendorff: okay
18:01jorendorffyeah, interrupting is the only async thing I know about
18:01jimbnbp: Yeah, I thought of both of those
18:03jimbjorendorff: My rule of the day is: "Thinking through the multi-threaded case is a great way to kill bad ideas."
18:03jimbhalf the time I realize I was about to do something completely insane
18:03nbpjimb: "write a compiler"
18:11mrbkapnbp: who releases the ScriptSource object when we call GiveUpBytecodeEncoding?
18:11nbpmrbkap: The GC.
18:12nbpmrbkap: roughtly at the same time as the CC, I hope.
18:15jimbnbp: I had been contemplating something that I just realized entailed calling ReleaseAllJITCode from a thread other than the one the JSRuntime belongs to. What could go wrong?
18:16jimb"Off to the races!"
18:18nbpjimb: worse.
18:19nbpjimb: we invalidate the Jit code which implies that you might be rewriting code as it is being executed :P
18:19jimbnbp: Well, it's utter chaos, is what it is.
18:19jimbnbp: There are some rules where it's not even worth thinking through the consequences of violating them.
18:19jimbunless you're bhackett
18:20nbpjimb: Rule #-1 ?
18:20djvjnaveed: ping
18:20jimbRight, Rule #-1 is "Unless you are bhackett."
18:20jimbLOL
18:21fitzgenfirebot: what is Rule #-1
18:21firebotfitzgen: Sorry, I've no idea what 'Rule #-1' is.
18:22fitzgenfirebot: "Rule #-1 is Unless you are bhackett."
18:22firebotfitzgen: ok
18:22fitzgenfirebot: what is Rule #-1
18:22jimbfitzgen: thanks
18:22firebotfitzgen: Sorry, I've no idea what 'Rule #-1' is.
18:22fitzgengr
18:22fitzgenfirebot: Rule #-1 is "Unless you are bhackett."
18:22firebotfitzgen: ok
18:22fitzgenfirebot: what is Rule #-1
18:22firebotfitzgen: I seem to recall that Rule #-1 is "Unless you are bhackett."
18:22jimbThere we go!
18:23fitzgenI am having particular trouble with my string quoting today
18:23jimbit's Wednesday's theme!
18:23jimbSorry, "It's Wednesday"'s theme.
18:26nbpmrbkap: Hum I wonder if we do not lose the last reference on the nsScriptLoadRequest while iterating over the linked list under GiveUpBytecodeEncoding.
18:27nbpmrbkap: in which case the buffer is going to be freed anyway.
18:29nbpmrbkap: Thus I should probably implement the second option of providing the output buffer as argument of the finish function.
18:29jorendorffI need a snappy acronym for the de-CPG bug
18:29jorendorffi'm thinking Mutliple Realms Bundled in Compartments with Alike Principals
18:29jorendorffMRBCAP
18:30tromeylol
18:31nbpjorendorff: sounds familiar.
18:31shujorendorff: +1
18:33nbpfirebot: what is MRBCAP?
18:33firebotnbp: Sorry, I've no idea what 'MRBCAP' is.
18:33shunow we just need blake to change his name to caplan
18:34nbpCompartments with Alike Principals Like my Another Nickname?
18:36jorendorffMultiple Realms, Bundled in Compartments, Aggregated by Principals
18:38nbpjorendorff: what is the 2 line summary of the JS team mtg?
18:38tcampbellshu: clearly MRBCAP is the toUpper version of mrbkap in jsapi-locale
18:39nbpjorendorff: is that the "Links " on the mailing list?
18:41jorendorffnbp: 0. see shu's email "Current JS Projects Newsletter", Mar 23, for what everyone's working on;
18:42nbpjorendorff: done.
18:42jorendorff1. since then djvj (with several people helping) has started work on intelligently scheduling GC work in Gecko; work also continues on incrementalizing a few more parts of GC.
18:44jorendorff2. arai will be very busy with university for the next 12 months, but will continue contributing here and there. currently arai is wrapping up work on async functions.
18:44jorendorff(consider item 0 as background, and it's 2 lines)
18:45nbpOk.
18:47nbpjorendorff: thanks :)
18:48nbpjorendorff: is that a regular meeting, or just a one time thing to answer specific questions?
18:48jorendorffnbp: hmm. I said I would ask people if they felt it was useful. but I did not actually do that.
18:51tcampbellI am +1 on meetings
19:09shui am -1 on it being at 7am
19:14tcampbellsympathize. that seemed cruel
19:54jimbjorendorff: Who could explain what JSContexts mean now?
19:56jorendorffjimb: This is probably best http://searchfox.org/mozilla-central/source/js/src/jscntxt.h#85-86
19:57jimbjorendorff: "Let me searchfox that for you"
19:57jimbjorendorff: Okay, so JSContexts are 1:1 with threads using a given JSRuntime?
19:57jorendorffafaict, yes, but I'm not sure
19:58jorendorffjandem probably knows
20:00jorendorffjimb: http://searchfox.org/mozilla-central/source/js/src/jsapi.h#1019-1024
20:01jimbjorendorff: Whoa, JSContext has got lots of js::ThreadLocalData<Foo>. Oh, but that&#39;s not TLS. Almost the opposite of TLS, actually.
20:02jimblurvely
20:02jorendorffright
20:04jorendorffjimb: http://searchfox.org/mozilla-central/source/js/src/vm/Runtime.cpp#64
20:09jimbjorendorff: Okay, I think TlsContext is probably exactly what I need.
20:09jimbjorendorff: Thanks for helping me look through this!
20:10jorendorffhappy to
20:10jorendorffi have an ominous feeling for some reason
20:10jorendorff...it&#39;s probably nothing
20:41mccr8shu: ping. I have a question about getOrCreateNonSyntacticLexicalEnvironment
20:51shumccr8: pong
20:52mccr8shu: I&#39;m looking at reviving bug 1186409 and wondering how NonSyntacticVariablesObject should interact with the nonSyntacticLexicalEnvironments_ stuff
20:52firebothttps://bugzil.la/1186409 ASSIGNED, wmccloskey@mozilla.com Use a single global for all JSMs
20:53shumccr8: gimme 2 minutes
20:53mccr8sure
21:00shumccr8: all right, so
21:01shumccr8: those two things are separate but should also work fine together
21:02mccr8I can hack it up so that a NonSyntacticVariablesObject gets used as a key if it is passed in, but I don&#39;t know if that makes sense or not
21:03shumccr8: in ecmascript, for each global there&#39;s a global lexical scope. getOrCreateNonSyntacticLexicalEnvironment is the hack that keeps that 1-1 relationship between a global with the global lexical scope when we use a &quot;fake&quot; global for the sake of capturing bindings or whatever
21:03shumccr8: all it does to keep the 1-1 relationship is to associate the &quot;fake&quot; global with a lexical env in a weak map
21:04shumccr8: right now, there&#39;s an additional invariant that all non-syntactic scope chains are wrapped by WithEnvironmentObjects
21:04shumccr8: seems like it should be fine to expand that invariant to include NonSyntacticVariablesObjects
21:05shuerr, s/scope chains/env chains/
21:05mccr8shu: ok, great. and there&#39;s no &quot;extra&quot; object associated with the NSVO so I don&#39;t need to do the .object() thing like is done for With?
21:06shumccr8: right,
21:06shumccr8: currently the API works by taking in an external object that&#39;s supposed to be the standin for the global environment, then wrapping it in a With
21:06shumccr8: don&#39;t think there&#39;s an option that says &quot;create one for me&quot;
21:08shumccr8: well, the API currently behaves differently
21:08mccr8shu: Bill&#39;s patch deals with that by adding a JSAPI call to create an NSVO, then constructs the chain, then adds some code to not do the With() wrapping if you pass in an NSVO
21:08shumccr8: sit down for a tale of qualified vs unqualified vars
21:09shumccr8: are you familiar with the distinction?
21:09mccr8if you can describe everything in terms of typed lambda calculus it might help. ;)
21:09mccr8shu: is that saying &quot;var foo =&quot; vs &quot;foo =&quot;?
21:09shuhow typed
21:09shusimply typed
21:09shuwhere on barendregt&#39;s cube you want it
21:10mccr8I&#39;ve done a fair bit of programming in the calculus of inductive constructions!
21:10shuok! that&#39;s all useless now because this is javascript
21:10mccr8hah
21:10shumccr8: yeah, so with a &#39;var&#39; makes it qualified, without var makes it unqualified
21:11shumccr8: the kind of objects that &quot;capture&quot; a qualified var assignment are called &quot;qualified variables objects&quot;
21:11Manishearthsfink: ping
21:11shumccr8: the kind that can capture unqualified bareword assignments are called &quot;unqualified variables objects&quot;
21:11mccr8makes sense
21:11shumccr8: a regular global object is both, but say, a function activation, is only qualified
21:12sfinkManishearth: pong
21:12shumccr8: okay, so, for *non-syntactic* With-wrapped stuff, which is what the current non-syntactic environment API uses,
21:12shumccr8: that is *only* a qualified var obj, so it doesn&#39;t capture bareword assignments
21:12Manishearthsfink: I&#39;m calling .Trim() on an owned nsAutoString, and the heap analysis doesn&#39;t like it -- what should I do?
21:12shumccr8: i don&#39;t actually know why that should be, but i think it&#39;s needed for code to work or something and our chrome code assumes that to be true
21:13shumccr8: an NSVO is both an unqualified and a qualified var obj
21:13shumccr8: so if you switch, there&#39;s a semantic change and things might break
21:13sfinkManishearth: ugh, that sounds like yet another of the string ops. My guess is it&#39;ll require an annotation.
21:13shumccr8: but from the non-syntactic lexical env weak map POV, it doesn&#39;t matter
21:13Manishearthsfink: how/where?
21:13mccr8shu: well, this is for loading JSMs. So I think those should be more isolated, so the NSVO sounds right.
21:13mccr8shu: how does const fit into this?
21:13shumccr8: okay, great
21:13sfinkManishearth: http://searchfox.org/mozilla-central/source/js/src/devtools/rootAnalysis/analyzeHeapWrites.js#399
21:14shumccr8: const are lexical bindings like lets, so go on the global lexical env
21:14shumccr8: JSMs used to depend on consts making properties on the global object itself
21:14sfinkwell, maybe after line 402
21:14Manishearthsfink: also, ni?d you about the placement new thing -- when you do Foo* foo = new(bar) Foo;, and bar is whitelisted, foo is considered a new heap object, not a whitelisted one
21:14shumccr8: but we patched those in that terrible ordeal a year or two ago
21:14sfinkyeah, I was just looking at what the analysis was saying about that one
21:15mccr8shu: ok, makes sense. Thanks. I&#39;ll work on this weak map thing and see how it goes.
21:16shumccr8: cool
21:17Manishearthsfink: thanks
21:19Manishearthsfink: fine if I stick an r=you on https://hg.mozilla.org/try/rev/325f6744afd74d28cbbea101c0ceb806ec956d68 ? assuming it passes
21:19sfinkManishearth: yes, of course
21:19Manishearththanks
21:21ehsan___tcampbell, ping
21:45jimbIs the idea behind JS_ResumeCooperativeContext / JS_YieldCooperativeContext that threads will typically be paused whenever they are not the active thread?
21:47jimbThis must be true, because otherwise all the existing code that makes JSAPI calls would fail whenever the running thread&#39;s context is not active.
21:53Manishearthsfink: fwiw I&#39;m using a workaround to the placement new thing (Instead of using system I&#39;m just using aDest)
21:53Manishearthso I may land my patches before the placement new fix hits
21:53sfinkah, ok
21:53Manishearththanks for looking into this, though!
21:54sfinkI&#39;m putting the placement new thing up for review now, but I don&#39;t know if (1) bhackett will be available for reviews, or (2) whether he does reviews via mozreview
21:56Manishearthkay
21:57sfinkjimb: yes, I believe that&#39;s currently the case. There was some intention in the future of allowing threads to run concurrently while they&#39;re in non-system compartments, since they shouldn&#39;t be able to share data in that case.
21:57sfinkwhich is somewhat terrifying
21:58jimb&quot;Well, then, we just won&#39;t make any mistakes!&quot;
22:03sfinkis jitcode shared across compartments within a zone?
22:10efaustsfink: I don&#39;t think soi
22:11sfinkhm. I wonder why there&#39;s no JitCode::compartment() then.
22:17sfinkoh. JSObject::compartment() doesn&#39;t at all do what I thought it did.
22:20jimbI wish searchfox.org were a &quot;Search Provider&quot;, so I could just make it my default instead of Google.
22:21efaustthat sounds like a problem for the man who just walked in ;)
22:21jimbDid billm just walk in?
22:21billmwhat&#39;s the problem?
22:22jimbbillm: Your software is too good, and it&#39;s become inconvenient for me to use it constantly.
22:22jimbbillm: I wish searchfox.org were a &quot;Search Provider&quot; so I could add it to my search box in Firefox.
22:23billmjimb: why not use a keyword search?
22:23jimbI guess I could do that
22:23jimbthat&#39;d be better
22:23billmjimb: I started working on an add-on that would do autocomplete a while ago, but I never finished it
22:24evilpiebillm: https://developer.mozilla.org/en-US/Add-ons/Creating_OpenSearch_plugins_for_Firefox
22:24evilpieopensearch supports suggestions
22:25jimbthis keyword is a nice 85% solution tho
22:25billmevilpie: yeah, but then you need a way to choose to use a given search plugin
22:25billmmaybe there&#39;s a way to do that, but it&#39;s not easy to find
22:25billmI still want Ctrl-K to go to google most of the time
22:26jimbright
22:26evilpieif you include that link tag in your page it&#39;s going to be auto discovered and you get that green icon in your search bar
22:26evilpiehttps://developer.mozilla.org/en-US/Add-ons/Creating_OpenSearch_plugins_for_Firefox#Autodiscovery_of_search_plugins
22:26jimbevilpie: Right, but the problem is that OpenSearch requires you to explicitly switch search providers, and then it&#39;s a mode.
22:26evilpiefwiw I use a keyword search as well
22:27jimbevilpie: I want to use searchfox.org for one search, without changing how search behaves the next time.
22:27billmthe add-on I was working on allows you to type &quot;sf nsGlo&quot; in the address bar and it will suggest things like nsGlobalWindow
22:27evilpieoh right, webextensions have some simple API for that
22:27jimblurvely
22:28billmyeah, it uses the omnibar api
22:28billmanyway, I should probably post what I have. I think it basically worked.
22:28evilpieactually now that you mention it
22:28evilpiesomebody implemented this https://github.com/mdn/webextensions-examples/tree/master/firefox-code-search
22:29jimbOh. Matt Wien used to sit just behind me
22:30jimb*Wein
22:30billmhuh, cool
22:30billmmine works a little better since it does autocomplete on the server, but that&#39;s nice
22:35jimbsfink: So in this future world where multiple JS threads run concurrently in separate MRBCAPs, JSAPI operations that affect shared resources would take locks?
22:36Waldo(someone&#39;s made the obvious MRBCAP/mrbkap joke already, right?)
22:36sfinkjimb: yes, though I&#39;m not sure what I misspelled mrbkap is
22:36jimboh yes
22:36jimbWaldo: it&#39;s beneath you
22:36Waldojimb: you know better than to claim that
22:37jimb<jorendorff> i&#39;m thinking Mutliple Realms Bundled in Compartments with Alike Principals
22:37jimbWaldo: I figured I&#39;d try
22:37Waldo:-D
22:37jimbsfink: ^^
22:37Waldowasn&#39;t reading scrollback, didn&#39;t realize it was a deliberate backronym
22:37sfinkyeah, I was seconds too slow on the joke
22:37Waldoprobably should have assumed it was
22:39sfinkjimb: this would mean locking whenever entering the system compartment. It is assumed that no context will ever have two different zonegroups (MRBCAPs?) on its stack
22:39jimbsfink: What will happen to nested event loops?
22:39jimbsfink: Don&#39;t answer that, it&#39;s going to be horrible
22:40jorendorffWaldo: by &quot;beneath you&quot;, I assume jimb means that the joke is in your scrollback.
22:40jorendorffWaldo: He uses Emacs as his IRC client, configured so that the newest entry in the conversation is always on top (you know, like email) and often forgets that not everyone does this
22:40Waldoo_O
22:40jimbthat is not true
22:40Waldolol
22:40jimbwell it&#39;s not entirely true
22:40Waldosounds truthy to me!
22:40jorendorffwell the alternative is that he means there are depths of punnery to which Waldo would not sink, out of moral feeling
22:41Waldoand we must assume the best of people, right?
22:41jimbYes!
22:42sfinkjimb: oh, nothing complicated. We&#39;ll just be segmenting the thread local stacks into mmapped pages that we can lazily convert individually into continuations to enqueue onto... never mind, I&#39;m trying too hard
22:43sfinkbut seriously, I believe that along with the zone group / tab group stuff, we have would separate event loops for each tab group
22:43jimbsfink: Yes, and it actually only requires code changes to a few spots, although once the change has landed, we must be careful to only use file descriptors whose numbers are a multiple of the thread id
22:43jimbsfink: Oh, and cache flush instructions now cause network activity
22:43sfinkbillm could probably give a better idea of what&#39;s going on with that
22:44jimbsfink: But aside from that, it&#39;s pretty much clear skies
22:44efaustWaldo: I have a random C++ question for you?
22:44Waldoefaust: as long as you don&#39;t expect a cryptographically secure answer, shoot
22:44jimbsfink: Separate event loops per tab group sounds very Servo!
22:45efaustWaldo: e.e
22:45jimbWaldo: I forbid you from answering efaust&#39;s question unless you prefix your answer with &quot;non_crypto::&quot;
22:45billmjimb: sorry, what&#39;s the question?
22:45Waldojimb++
22:45efaustWaldo: so class statics, are they laid out in memory as obviously as you&#39;d hope? Sitting in .data with some mangled name?
22:46Waldoefaust: I&#39;m not sure there are any enforced guarantees on how class statics (or any statics) are laid out, but I can&#39;t say I *know*, because it seems like the sort of question best answered by evading the need to ask it
22:46Waldojust like hairy edges of English grammar -- just write the sentence differently
22:47efaustWaldo: oh, I don&#39;t *need* them to be
22:48jimbbillm: There are future plans to have threads run concurrently in sufficiently distinct compartments. But there are naturally details of SpiderMonkey that are runtime-wide. So will SpiderMonkey use locking internally to protect these shared structures, or what?
22:49billmjimb: it depends on whether you&#39;re asking about the cooperatively scheduled world or the preemptively scheduled world
22:49billmjimb: for cooperative scheduling, we mostly don&#39;t need locks as long as we only switch tasks at safe places
22:50jimbbillm: The cooperatively scheduled world uses the JS_ResumeCooperativeContext and JS_YieldCooperativeContext calls, and that part makes sense to me.
22:50jimbbillm: My understand there is that when you&#39;re yielded, you&#39;re usually blocked or exiting.
22:50jimbbillm: But specifically, you&#39;re *not* using JSAPI, so you don&#39;t actually need locking.
22:50jimbbillm: So that matches what you said.
22:50billmjimb: I think that&#39;s not true. when you yield, some JS code from a different ZoneGroup can run.
22:51billmjimb: but maybe I misunderstood you
22:52billmjimb: the purpose of yielding is to allow JS code for a different tab to run
22:52Manishearthsfink: there?
22:52jimbbillm: Yes.
22:52sfinkManishearth: yes
22:52billmjimb: and it runs on the same runtime
22:52jimbbillm: But it would run in a different thread, right?
22:52billmjimb: yes
22:52Manishearthsfink: it still fails
22:52Manishearth_ZN8nsString4TrimEPKcbbb$void nsString::Trim(int8*, uint8, uint8, uint8) @ xpcom/string/nsTStringObsolete.cpp#633 ### SafeArguments: <this> aDefaultVariableFont
22:52billmjimb: your thread would just be blocked
22:52Manishearth_ZN10nsRuleNode17ComputeSystemFontEP6nsFontN7mozilla11LookAndFeel6FontIDEPK13nsPresContextPKS0_$void nsRuleNode::ComputeSystemFont(nsFont*, uint32, nsPresContext*, nsFont*) @ layout/style/nsRuleNode.cpp#3580 ### SafeArguments: aDest
22:52ManishearthGecko_nsFont_InitSystem @ layout/style/ServoBindings.cpp#1005 ### SafeArguments: <arg0>
22:53Manishearthsfink: it seems to have caleld nsString::Trim instead of nsAString::Trim?
22:54jimbbillm: Let me try to say it again: Threads are 1:1 with JSContexts. When a thread/context yields the runtime, it is expected not to make any other JSAPI calls until it becomes the active context on that runtime again. Correct?
22:54Manishearth( failure in https://treeherder.mozilla.org/#/jobs?repo=try&revision=cb4e3fc7ff513d8facc6c16dc3bd83e3119afce1 )
22:55billmjimb: oh yes, that&#39;s true
22:55jimbbillm: Okay. And the reason this expectation is easy to meet is that while you&#39;re not the active thread/context, you&#39;ll usually be blocked anyway?
22:55jimbwaiting to become active again
22:55billmjimb: yes
22:55jimbbillm: okay
22:55jimbbillm: So now we can talk about the preemptively scheduled world
22:55billmjimb: for preemptive threading, the idea is to avoid most runtime-wide operations. GC will need significant changes, for example.
22:56billmjimb: and in some cases we will just have to take locks I imagine
22:56jimbbillm: Okay. And all the other random crap in the 766-line definition of JSRuntime will have to be synchronized in one way or another.
22:56jimbor replicated per-thread or whathaveyou
22:57billmjimb: I guess so. there are a lot of wrappers around data in there to try to classify how stuff should be accessed.
22:57jimbyeah, I noticed.
22:57billmjimb: I don&#39;t have any plans to work on preemptive threading. it&#39;s bhackett territory.
22:57jimbbillm: js::ThreadLocalData made me think &quot;TLS&quot; at first, but it&#39;s actually almost the opposite
22:58jimbbillm: I know what you mean.
22:58billmjimb: well, it&#39;s sort of like the thing you put around data you get from TLS :-)
22:59jimbbillm: Nice try
22:59Manishearthsfink: so the issue is that I&#39;m mutating a string
22:59Manishearthbut it&#39;s a string I created!
22:59jimbbillm: Thanks very much for the background.
23:00billmjimb: sure, np
23:01sfinkManishearth: I think I may have messed up the argument naming. It&#39;s claiming nsString::Trim has a parameter aDefaultVariableFont? Oops.
23:02Manishearthheh
23:03Manishearthsfink: so what should I do here?
23:05sfinkManishearth: sorry, was doing something else for a minute. Looking...
23:05Manishearthnp
23:05Manishearththe function creates an nsAutoString, and calls .Trim on it. .Trim() does mutate it
23:05Manishearthbut it&#39;s owned, so that should be okay?
23:06sfinkManishearth: oh. It&#39;s not complaining about a mutation that it can see. It&#39;s complaining about memchr, an external function call, that it assumes will kill -9 you and shoot your cat.
23:06Manishearthyes
23:06Manishearththat is true, memchr has often attempted to shoot my cat
23:06sfinkthat needs to be added to http://searchfox.org/mozilla-central/source/js/src/devtools/rootAnalysis/analyzeHeapWrites.js#40
23:07Manishearthsfink: I can whitelist memchr, but my question is -- won&#39;t it still complain about the trim?
23:07Manishearthor is it smart enough to not do that?
23:09* Manishearth pushes to try
23:09Manishearthkinda wish i had a way of running this locally
23:09sfinkManishearth: I can&#39;t promise it won&#39;t, but given that <this> is safe, and the function is annotated, it *should* allow writes to fields of nsString
23:09sfinkthough you may need to widen you annotation to include nsString::Trim as well as whatever it was
23:09Manishearthsfink: well
23:09ManishearthnsString::Trim is not safe in genera
23:10sfinkManishearth: I can probably set you up to run it locally without too much trouble
23:10Manishearthbecause you may call it on a reference to a heap nsString elsewhere
23:10Manishearthit&#39;s only safe if you own the nsstring
23:10Manishearthsfink: on a mac? would be nice
23:10sfinkbut then &#39;this&#39; wouldn&#39;t be considered safe
23:10Manishearthoh ok
23:11sfinkyes, a mac is fine, since you wouldn&#39;t be doing the analysis build, just running on the generated files
23:11sfinkstep 1: add &quot;--upload-xdbs&quot; to a try push of interest
23:12sfinkI have to go in 2 minutes, so I&#39;ll make an attempt at writing up the further steps in an email. (I should be back online within half an hour or so. If my video drivers allow me.)
23:12Manishearthsfink: cool, thanks
20 Apr 2017
No messages
   
Last message: 92 days and 7 hours ago