mozilla :: #jsapi

17 May 2017
01:45mrgigglesthe mozilla-inbound tree is now open
02:39RyanVMwe have SM fuzzing builds on TH now?
03:59shumrgiggles: pun
03:59mrgigglesshu: Two silk worms had a race. They ended up in a tie.
08:25tillglandium: ping
08:25glandiumtill: pong
08:26tillglandium: can you take a look at bug 1277338 again? Clearly we're not doing the right thing there, but unfortunately it's very unclear what would be the right thing, and I don't know who else to ask
08:26firebot NEW, Move rust-mozjs bindings into mozilla-central
08:27glandiumtill: I haven't worked out a solution, except something with .cargo/config, which actually sucks because it requires settings for each and every different target affected
08:28tillglandium: yeah, all of this is a mess :(
08:28tillglandium: it's blocking us from using unmodified SpiderMonkey in Servo, and from using jemalloc in SpiderMonkey in Servo, which is very unfortunate
08:29glandiumtill: use --disable-jemalloc?
08:29glandiumthat should make you use rust's jemalloc
08:30tillglandium: oh, I was under the impression we'd just fall back to the system allocator in that case
08:30glandiumtill: well, if you build mozjs as a shared library, it might
08:30glandiumnot if you build it as a static lib
08:39tillglandium: so --disable-jemalloc should fix the issues fitzgen describes in because jemalloc is the only thing we're using from mozglue? And the answer to the question he asks at the end of that comment is "no"?
08:39firebotBug 1277338 NEW, Move rust-mozjs bindings into mozilla-central
08:40glandiumtill: I doubt jemalloc is the only thing you use from libmozglue... mfbt is in there
08:40glandiumalthough there aren't a lot of cpp files in mfbt
08:41glandiumand the answer to the question at the end is "maybe, but I need to think more about it"
08:41tillglandium: that's what I feared, yes. So --disable-jemalloc doesn't solve the real issue, it seems
08:41tillglandium: ok, thanks
08:42glandiumtill: maybe it works around it, I don't know. You can try
09:43Yoricshu: djvj: The more I think about it, the more I am convinced that we should aim to specify BinJS as a generic way to unpack ESTree-style ASTs. It just happens so that the ESTree AST itself specifies a representation of EcmaScript.
10:08jonco*wonders whether mozreview will let him download a raw diff*
10:08joncooh yeah, nm
14:15sfinkjonco: ping. Are we meeting now? I've lost track.
14:24joncosfink: oh I have the meeting as 4:45 in my calendar, but can't remember what we agreed
14:26joncosfink: can do it now if you like
14:59sfinkjonco: sorry, I need to go to my kid's school now for an hour or two
15:18philoroh boy, way way more async generator test262 tests to fail on beta
15:20philorextra nice on Android, where we split them among 13 failing chunks to maximize the orange
15:20mconleyHas something changed with the GC lately? In like, today's Nightly?
15:20mconley <-- I&#39;m getting horrible performance on some pages
15:20mconleylike multi-second main thread hangs
15:20mconleydjvj: ^-- ?
15:22joncomconley: I don&#39;t think there have been any big changes in the last few days
15:25* mconley files bug 1365632
15:25firebot NEW, Multi-second main thread hangs in GC when visiting (and maybe
15:44florianHi. I&#39;m seeing in startup profiles that there&#39;s a little bit of time spent GC&#39;ing. Would it make sense to disable garbage collection until the first window is painted?
15:49joncoflorian: it would be good to know what&#39;s triggering those GCs
15:50joncoflorian: we can always improve our GC scheduling and taking account of whether we&#39;re in startup could be an input into that
15:51djvjjonco: GC meeting now?
15:52djvjmconley: not that I know of..
15:52djvjmconley: we should bisect if we have a recent regression
15:53florianjonco: Here is a startup profile with 14ms spent in minorGC
15:53djvjsstangl: are you going to be at workweek in TO next week?
15:58sstangldjvj: no, but I&#39;ll be around for vidyo if that&#39;s necessary
16:02smaugflorian: hmm, minorGC is possibly trickier to postpone
16:03smaugsince if nursery is full, one needs to do something with it. But I&#39;ll let gc folks to clarify
16:31joncoflorian: is this a nightly build? you should disable poisoning by setting JSGC_DISABLE_POISONING=1 as this will affect performance measurements
16:32leobaltershu: I believe I&#39;m falling behind if I only run Test262 locally with runtime hosts (SpiderMonkey, V8, etc). Is there anyway to execute Nightly in the CLI as we do with the jsshell?
16:33leobalterIf we have that I could even experiment some CI stuff for Test262. WPT has some good interaction with browsers in their CI, but they load html.
16:35florianjonco: yes it&#39;s a Windows nightly, on the quantum reference hardware
17:13leobalterI can probably do this with test262-harness, let&#39;s try
17:23leobalterthe answer is probably around this:
17:46jorendorffsfink: honestly the GC api is incredibly hard to use
17:46jorendorffsfink: this seems harder than adding Symbols
17:48jorendorffsfink: more productively: is a GCPolicy&#39;s needsSweep() always called only during sweeping, i.e. can it assert that my_zone().isGCSweeping()?
17:51jorendorffsfink: hi! couple of GC questions for you
17:51jorendorffsfink: 1. is a GCPolicy&#39;s needsSweep() always called only during sweeping, i.e. can it assert that my_zone().isGCSweeping()?
17:52jorendorff2. assuming we&#39;re sweeping, which variant of IsAboutToBeFinalized should I call, and what header is it declared in?
17:54jorendorff3. the rationale on JSCompartment::maybeGlobal() seems out of date, can you help me update it?
17:54jorendorffIt says that a Compartment can be without a global if &quot;e.g. a string in a compartment is rooted but no object is, and thus the global isn&#39;t rooted, and thus the global can be finalized while the compartment lives on&quot;
17:54jorendorffbut strings aren&#39;t &quot;in&quot; compartments anymore, are they?
18:13sfinkjorendorff: I&#39;m not entirely sure. I would be wary of asserting that. You would use IsAboutToBeFinalizedUnbarriered, defined in gc/Marking.h, and it handles the zone->isGCSweeping() case as well as other cases.
18:14jorendorffThat &quot;not entirely sure&quot; is in response to question 1, right?
18:14sfinkand you are correct, strings are in Zones now
18:14jorendorffso is there anything other than objects in Compartments now?
18:14sfinkI&#39;m not sure what could keep a compartment alive past its global these days
18:14sfinkI&#39;m looking
18:15jorendorffthank you so much
18:15jorendorffThis is honestly a struggle for me
18:16sfinkJSScript looks like it&#39;s in a compartment, but I&#39;m not sure if there&#39;s a way to have a JSScript without a global
18:18sfinkand js::wasm::Instance, whatever that is
18:18sfinkso afaict, compartments hold objects, object groups, scripts, and wasm instances nowadays
18:19sfinkbut it&#39;s done by having a compartment_ field lying around, not by physically locating them in a compartment-specific arena
18:20sfinkthe memory layout is determined by zones
18:20jorendorffsfink: Another possibility is, we create a compartment and never even create a global for it
18:20jorendorffsfink: we probably do that for the atoms compartment
18:20sfinkgood point
18:20sfinkyes, I think that pretty much has to be right, given that the atoms compartment is shared all over the place
18:21jorendorffI&#39;ll take a stab at that comment and r?you
18:21sfinkdo we still have an atoms compartment, or is it an atoms zone now, I wonder?
18:21jorendorffwe definitely have the latter... and I&#39;m sure I&#39;ve seen comments referring to the former
18:21jorendorffbut it&#39;s worth checking
18:22sfinklots of function and class names too
18:23jorendorffsfink: what about cross-compartment wrappers? suppose we substitute one of those for &quot;strings&quot; in the reasoning
18:23jorendorfffor how a compartment can outlive its global
18:24jorendorffhypothetically, we create a compartment and global; some code runs in there, creating a CCW (an outward edge)
18:24jorendorffthe CCW maybe *doesn&#39;t* have a strong reference to the global (?)
18:24sfinkCCWs are objects, aren&#39;t they? So they&#39;ll mark their global.
18:24jorendorffoh, they do? I didn&#39;t know, in the case of proxies
18:24jorendorffyeah of course they do
18:25jorendorffthat&#39;s the thing about thinking too far ahead: you start thinking of the future as the status quo. #timetravelproblems
18:25sfinkrelates to the latest advice on not announcing what you&#39;re doing, because you tend to think of it as fait accompli
18:27sfink looks to be related weirdness, but I don&#39;t think it probably changes anything for you
18:42jorendorffsfink: ok, so how about this
18:42jorendorffsfink: it uses the word &quot;objects&quot; in a way that makes me think it might not mean JSObjects
18:42jorendorffthat could mean strings, and we&#39;d be back in business, so to speak
18:43jorendorffbut wait, what would be keeping strings alive in a zone, if not some object
18:43jorendorffmakes no sense
19:00shuleobalter: are you asking for a way to run nightly headless for testing?
19:00shuYoric: i&#39;m not sure i understand the proposal of unpacking ESTree-style ASTs
19:01shuYoric: what does that mean exactly
19:03shuYoric: if this is the same idea as presented in the gist comment, what do we gain from allowing less compact encodings?
19:03shuYoric: i&#39;ll comment on there
19:06leobaltershu: It seems like the best way to do it is by some similar approach of WPT Runner, using webdriver
19:06shuleobalter: i&#39;m afraid you&#39;re on your own there, i don&#39;t know any of that stuff
19:06leobalterGeckodriver can help me using the latest Nightly
19:06leobalterbut the implementation is complex
19:07shuleobalter: is this in relation to the improve-workflow thing or an independent test262 thing?
19:07leobaltershu: that&#39;s why I am hired anyway. This can help improving the workflow, but I&#39;ll just check if it&#39;s a real fit for the scope of this contract before getting into a rabbit hole.
19:08shuleobalter: i think it&#39;s not a fit for the scope of the current problem -- there are a lot of pain points for working with *just* the shell
19:09leobalterthe problem: waiting for the try-server takes too long. I should be able to verify the tests in the browser as well.
19:10leobalterlike, if I can do this before the try-server, in a faster way, it would save me a time. But for sure, this might be a small concern and specific to Test262 only.
19:10shuleobalter: i think that&#39;s more specific to your workflow as a test262 maintainer
19:11shuleobalter: for a feature implementer or a bug fix, testing these things can be fire-and-forget to try, it doesn&#39;t need to block other work
19:11shuleobalter: since for almost everything, having new language-only features pass in the shell gives you high confidence it&#39;ll pass in the browser
19:12shuleobalter: as a test262 maintainer, otoh, you have to worry about weird API surface intersections like global getters and the such
19:13shuleobalter: so what i&#39;m saying is i agree that it&#39;s a problem, but can be deprioritized
19:13leobalterI agree
19:14leobalterI can also try to delegate this to some coworker using open source time or Rick who is working in the CA with Google
19:15shuleobalter: yeah -- headless mode gotta help somehow? i know chrome released a headless mode recently, and we are working on our own iirc
19:16leobalterheadless feels like way easier to integrate
19:17leobalterbut anyone doing this should investigate WPT implementation too
19:17shusounds up bocoup&#39;s alley :)
19:18leobalterthere&#39;s a team here improving it already :)
19:25shujimb: how come you don&#39;t like subtrahend :(
19:26* shu pours one out for subtrahend
19:30Yoricshu: It&#39;s actually not the same as the long gist comment.
19:52jimbshu: subtrahends, man, you just can&#39;t trust &#39;em
19:53jimbthey always take, take, take
19:53jimbAnd they get all negative if you ask them to give
19:53jimbbut that&#39;s just my opinion
19:54jimbshu: (because it&#39;s too generic; it doesn&#39;t add any information at the site of use.)
19:57shuYoric: oh do you mean we should just try to adopt estree
20:29Yoricshu: So, my general train of thoughts goes in a few (mostly converging) directions: 1/ it&#39;s easier to specify decoding BinJS than to specify a 1:1 mapping between BinJS and EcmaScript source we don&#39;t care all that much, for instance, if the same source code can be encoded to several distinct BinJS files, as long as the decoding is correct;
20:31Yoric2/ it&#39;s easier to specify decoding to an AST than to a BNF;
20:31shuYoric: i&#39;m confused
20:32Yoric3/ hey, some people have already looked at a way to specify an AST for JavaScript, lucky us :)
20:33shuYoric: if there is a single correct decoding, what do we gain by not speccing that single correct decoding as also the encoding?
20:33shuYoric: i don&#39;t know why 2) would be true either
20:35shuspeccing decoding an AST seems exactly the same as speccing an AST in my mind
20:35shuby &quot;grammar&quot; in previous discussions i meant the structure of the AST
20:44sfinkjorendorff: sorry, I&#39;ve only been sporadically around today. (Spent the morning doing multiple things at my kids&#39; school, crouched over a sunlit laptop screen in between.)
20:44sfinkjorendorff: you are correct, that comment is using &quot;objects&quot; to refer to GC things
20:45sfinkwe could now say Cells
20:46sfinkthough that comment was probably written when some people were using Cells to mean the things arenas are divided into, where a GC thing might span multiple Cells
20:46sfinkbut obviously &quot;object&quot; is colliding pretty hard with &quot;JSObject&quot; here, which isn&#39;t helping
20:51Yoricshu: Regarding 1/, let me give you a simple example. The current prototype already supports a format in which the same source code can be encoded in several different manners that will all be decoded to the same AST. The (only) choice at the moment is the order in which strings are placed in the strings table. Shuffle the strings at will (and propagate the
20:51Yoricchange to the AST itself) and you will obtain the same AST. I don&#39;t think that there is anything for us to gain by specifying the order of strings.
20:52YoricI am convinced that this is not the only case in which we can afford to be loose on the encoder, as long as we&#39;re strict in the decoder.
20:52shuYoric: indeed not -- in that case i think we&#39;re on the same page but using different terms
20:52shuYoric: the single AST that can be produced -- that&#39;s the thing with a grammar i want to spec and match up to ecma262
20:53shuYoric: the composable techniques to efficiently code that can be layered on top, like constant tables,
20:53shuYoric: that should have some wiggle room
20:53YoricAs for me, I&#39;m interested in specifying how to reach that AST, not as much in the exact AST :)
20:54shuYoric: i&#39;m not sure what that means
20:54YoricNever mind, it means that we concentrate on different parts of the problem.
20:55YoricIn this specific case, I realized that if I just replace our target AST by &quot;any AST written with the same conventions as ESTree&quot;, specifying decoding is pretty trivial.
20:57YoricI actually have a reasonably complete pseudo-code algorithm that specifies this.
20:57shuYoric: that&#39;s specifying a different thing than the tree, though, right?
20:58shuYoric: there you&#39;re just saying estree is the tree spec
20:58YoricYes, I&#39;m specifying the decoding, not the tree itself.
20:58shuyeah okay we&#39;re talking about different things
20:58YoricYes, I&#39;m saying that EStree is the tree spec.
20:59YoricFurther, I&#39;m saying that while it&#39;s entirely possible that we can come up with an alternative specification for an AST, well, EStree 1/ is already here; 2/ is already broadly used; 3/ actually works nicely for the decoder.
21:00Yoricshu: So, for the moment, I can&#39;t think of any convincing reason to not use EStree.
21:03shuYoric: the reason in my mind would be if it&#39;s hand-derived from ecma262, it doesn&#39;t solve the language bifurcation problem going forward
21:03shuYoric: but it&#39;s not like i&#39;ve done close inspection, it might turn out to be the thing to do going forward as well
21:04Yoricshu: On the other hand, if we come up with a new AST that&#39;s not EStree, we end up going against the flow, which is annoying. Pun not intended.
21:05YoricI think I could easily amend the BNF of ES to produce an EStree (at least for the cases covered by EStree, I don&#39;t know if they all are).
21:05shuYoric: well, we don&#39;t have the same customers, right
21:06YoricSure. But if you want to avoid bifurcation, let&#39;s not start with a bifurcation :)
21:07Yoricshu: Anyway, I&#39;m planning to log off for the night.
21:10shuYoric: estree is not a standard, and given that it&#39;s based on our internal ast, it could be a starting point
21:10shuYoric: but that&#39;s close to a &quot;spec an entirely different grammar&quot; approach
21:12shuYoric: it&#39;s convenient, but best case scenario in my mind is still we can somehow manage to generate estree from the actual grammar and then we can converge
21:13Yoricshu: Sounds like a plan. Note that EStree is probably loose enough that we can get away with specifying something EStree-like that can still be EStree-compatible.
21:13shuYoric: yeah, that&#39;d certainly be cool
21:39shuleobalter: \o/ fixing length
21:40shuleobalter: well, most of them anyways
21:46jorendorffsfink: sporadic/async is no problem. OK, I changed that comment to say &quot;cells&quot; instead of &quot;objects&quot;. But now
21:46jorendorffsfink: I still don&#39;t know how a compartment can have any live cells without the global being live
21:47jorendorffonly objects and a few other kinds are in compartments;
21:47jorendorffall objects mark the associated global
21:47sfinkI think it&#39;s likely that the situation is no longer possible
21:48jorendorffbut to complete the proof, we need:
21:48jorendorffeach of the other kinds also marks their global, either directly or indirectly
21:48jorendorffwhich list of kinds is relevant here?
21:49jorendorffsfink: I hope it&#39;s clear that proving this is a useful thing to do
21:49sfinkno, I don&#39;t think you need that, because I doubt it&#39;s true ;)
21:49sfinkI think you need to prove that the existence of any of those in the compartment implies the existence of at least one object
21:49sfinkso eg there&#39;s no way to have an orphaned JSScript
21:49sfinkuh, yeah, that
21:50jorendorffOK, admittedly that is slightly weaker than mine, but not much :)
21:50jorendorffsfink: *is* it possible to have a JSScript that doesn&#39;t mark a global?
21:50sfinkbut I don&#39;t know how to prove that it&#39;s impossible to orphan a JSScript
21:50sfinker... I dunno. Maybe scripts hold objects already, that&#39;d make it easy.
21:50jorendorffsfink: Rooted can always root a script or anything else in isolation
21:50* sfink looks
21:51sfinkthat is true
21:51jorendorffi.e. it could just be rooted on the stack, pretty much arbitrarily
21:51shugandalf: ping
21:51sfinkI&#39;m not sure it&#39;s possible to have a Rooted on the stack without entering the compartment, and entering the compartment will keep it live
21:51shugandalf: could you give me some whirlwind tour of Intl API stuff later
21:51shugandalf: like in an hour
21:51sfinkum, I wonder if it keeps it live by marking just the compartment, or the global...
21:52shugandalf: someone needs to review intl patches but i have no clue how the API works or anything
21:52shugandalf: great, i&#39;ll ping you in a bit
21:52jorendorffsfink: so this is weird... when gc starts, in markRoots or whatever ... we just mark all compartments
21:52jorendorffat least, that is what the code *says*
21:52jorendorffI&#39;m referring to code in GCRuntime::traceRuntimeCommon
21:53leobaltershu: I sent an email documenting the current ideas for the next steps on the workflow. It&#39;s too much to write those down here on IRC. In the meanwhile I&#39;m fixing the current open bug with the latest test262 update
21:53shuleobalter: got the email, will try to respond by tomorrow
21:53shuleobalter: for the HTML stuff
21:54shuleobalter: bakkot&#39;s web runner has some explicit logic in there that skips tests or something if a regexp matches certain identifiers
21:54sfinkhm, &quot;regardless of whether the compartment&#39;s global is still live&quot;. Another scary comment.
21:54sfinkregardless of whether the compartment&#39;s global is still live
21:54shuleobalter: that logic should be removed if test262 is going to make an effort to have everything runnable in a browser context
21:55sfink(sorry, emacs wasn&#39;t populating my paste buffer for some reason)
21:55sfinkjorendorff: so that&#39;s not marking the compartment itself, except possibly indirectly via a root
21:56sfinkand JSCompartment::traceRoots is what keeps the global alive if the compartment has been entered
21:56sfinkand it looks like it does it by tracing the global
21:57jorendorffsfink: I don&#39;t see where JSCompartment::traceRoots calls JSCompartment::traceGlobal
21:57jorendorffaha, there it is
22:01leobaltershu: yes, the idea is having test262 runnable in a browser context as well.
22:03shuleobalter: see comment in bug about failing built-ins tests
22:06sfinkjorendorff: I am writing this question up in an email to jonco. Either we can get his opinion, or I&#39;ll figure out the answer as a side effect of writing up the question.
22:06jorendorffgood plan
22:27sfinkjorendorff: email sent
22:27jorendorffsfink: second-best outcome! :)
22:27sfinkyou&#39;ll see that my (current) conclusion is that this case is now impossible
22:28sfinkwell, it&#39;s the first-best outcome with enough uncertainty due to complex reasoning and some uncertain assumptions that I still want a second opinion.
22:28sfinkso yeah, second best outcome :)
22:29sfinkI found the compartment types by grepping for &#39;JSCompartment* compartment()&#39;, which *might* not be the most foolproof plan ever.
22:30sfinkit really seems like it&#39;s a nice enough property that if it isn&#39;t true, we should make it true, at least until the jorendorff jerk comes along and messes it up by adding more possibilities
22:30jorendorffgrepping: heh!
22:30jorendorffsfink: omg that guy is such a jerk
22:43leobaltershu: yeah I looked at only one report. at least those seem to be the last lines
22:43shuleobalter: also, you can&#39;t delete comments on BMO
22:43shuleobalter: the point being there should be an immutable history you can consult as a source of truth
22:44leobaltersure thing. Sorry I was experimenting that &quot;edit as comment&quot; in the attachment.
22:48shuleobalter: no worries
22:50leobalterI would have to learn that anytime
22:51shugandalf: ping
22:52gandalfshu: pong
22:52shugandalf: got time for vidyo chat now?
22:53gandalf - Intl API is fun to work with
22:53gandalf - Intl has just one spec
22:53gandalf - Intl API has a lot of tests
22:53gandalftwo of the three are true
22:53gandalfshu: in 10 min pls?
22:53shugandalf: sure
22:55shuleobalter: so to confirm, the Array built-in tests are fixed, the Object built-in tests is a different bug
22:55shuthe Object built-in tests failing*
23:07gandalfshu: ready
23:09shugandalf: can you do vidyo?
23:09shugandalf: i don&#39;t have a laptop with me, and i have no audio on my desktop
23:09gandalfah, sure
23:09shugandalf: thanks, i&#39;ll be in your room
23:09gandalfI&#39;m in my room
23:18crowbotIssue #105: Complete the extension keys + options + resolvedOptions set -
23:22leobaltershu: yes, I sent a patch to Test262 for the Object build-in tests but that&#39;s not merged yet.
23:22leobalterI&#39;m also verifying the other items in the skip list while I wait for the try server
23:40leobaltershu: is complete now
23:40firebotBug 1365042 NEW, More than test262/language/{expressions,statements}/async-generators need to be skipped if release_o
23:45leobalterI have a small patch for tomorrow I&#39;m already running try server for it
18 May 2017
No messages
Last message: 92 days and 5 hours ago