mozilla :: #jsapi

9 Aug 2017
00:00glandiumsfink: btw, I radically changed the build-gcc script, and the --no-build option is no more
00:00sfinkaw, ok
00:01glandiumsfink: the script itself is a library of functions now, and you need to use it from separate scripts, that live in taskcluster/scripts/misc
00:01sfinkoh. So that might work out fine for me, then.
00:01glandiumsee e.g. taskcluster/scripts/misc/
00:05sfinklooks like the downloading and patching are separate, so it looks good for my use. I guess it'd be nice if the GPG keys and checksums were in an associative array or something so I could just source in a manifest and specify the version I want, but that seems minor. (And pushing the edge of what really ought to be done in a bash script.)
08:46charlesThe RHS operand of LAddI64 might be a stack allocation?
11:52nbpsunfish: What happened with the patch got wrapping numOperands and getOperand calls into some sort of iterator?
12:08nbpcharles: I would not expect so.
12:08nbpcharles: the Lowering is supposed to request a register allocation, otherwise yes, it might be.
13:49bbouvierjandem, decoder, ping, could people just not compile with tracelogger support instead? (cx = bug 1382997)
13:49firebot ASSIGNED, Assertion failure: TraceLogTextIdEnabled(TraceLogger_Scripts), at js/src/jit/CodeGenerator.cpp:9941
13:51jandembbouvier: there's only --enable-trace-logging and it's enabled by default in debug builds
13:52jandembbouvier: i suppose we could add a --disable flag, still not sure it's worth the maintenance burden
13:52bbouvierjandem, right indeed.
13:53bbouvierjandem, what do you think of us sending an email to dev platform / js internals, asking if there are users of traceloggers, or people who would be *immediately* interested in using it, and expanding devtools support?
13:53bbouvierjust to see if we should just remove it entirely or keep it in the code base
13:54jandembbouvier: even if people are interested in using it, we have to fix the open fuzz bugs and I'm not sure those people will be interested in that :)
13:54jandembbouvier: I'd be happy to email js internals though
13:55bbouvierjandem, but that could help re-prioritize work, maybe :) or even some JIT people don't know it yet, we have a bunch of newcomers these days!
13:55jandembbouvier: we could also make these functions no-ops if the fuzzing-safe flag is used, but that means it will break anyway
13:57bbouvierjandem, yes indeed; if we don't have an owner and no user interest (be it JIT devs or end users), it's basically dead code :/
14:49sunfishnbp: that's
14:49firebotBug 1234921 ASSIGNED, Optimize MIR Operands iterations
15:51sfinkjonco: ping
15:53joncosfink: hey
15:54joncosfink: just finding a room
16:38anbanaveed: ping
16:48joncosfink: bug 1387950
16:48firebot NEW, Adjust GC options to avoid (minor) GCs during Firefox startup
17:15nbpshu: Is this a valid generator syntax in the web?
17:15evilpienbp: no
17:16araiit had been removed from draft spec
17:16nbpbecause apparently we have that in one of our mochitest, and it seems to execute fine :/
17:16araimaybe we should hide it from web content
17:17nbparai: Either that, or I add a test case to xdr because this syntax of generator causes XDR failures.
17:18araiso, hiding it from web content is not sufficient?
17:19araican chrome/addon code also hit the failure?
17:21nbparai: no, chrome/addons are not using the incremental encoder yet.
17:21arai(I wonder if it makes sense to disable it at the same time as disabling other deprecated features
17:21nbparai: but if we keep it I might as well fix the bug.
17:22nbparai: should I needinfo you on the bug?
17:22araiyes, please :)
17:23nbpI attached the JS shell test case.
17:24nbpI guess this might be an easy fix, if we can get the location of the beginning of the expression, as use it as the sourceStart_.
17:25nbpor if no other functions can live under it, we might as well alias the sourceEnd and the sourceStart, but this might produce confusing error messages.
17:35araifunction can be written inside its body (not sure about Xdr's context tho)
17:38araiso, I guess, sourceStart_ just need to point "(" before "for", right?
17:41nbparai: right
17:42nbparai: the incremental encoder asserts that functions are stack into each others.
17:42araiah, I see
17:43nbparai: this is an assumption required to prevent generating a fake AutoXDRTree key which represent a special value, such as the source, or the top-level.
17:44nbparai: and also to ensure that no 2 functions get the same key.
17:50araiso, I think we just need to call FunctionBox::setStart for it
17:51araialso, perhaps pass begin instead of 0 here
17:51araifor consistency
17:56shunbp: wait what, comprehensions are content visible right now?
18:06* bz really wishes he could build all of the browser debug except spidermonkey
18:06bzOr figure out some other way to have a usable spidermonkey in debug builds
18:22arainbp: can I take bug 1385310 over?
18:22firebot ASSIGNED, Assertion failure: uint32_t(parent->key_ >> 32) <= uint32_t(child->key_ >> 32) && uint32_t(child->ke
18:57nbparai: sure
18:58nbpshu: apparently, or we load this script in a priviedge document.
18:59araithanks :)
19:00arai|alert((for (x of [1]) x));| works in normal webpage
20:37emilioIs there anyone around for a question re. the rooting hazard stuff?
20:37sfinkemilio: sorry, yes, I&#39;m here now
20:38bzemilio: I might be able to answer those too
20:38emiliosfink: so, my patch devirtualizing atom refcounting caused the hazard analysis to complain
20:38emiliosfink: with something like the following:
20:38sfinkyeah, I just looked at your link again
20:39emiliobz: cool, will have it into account for the next time ;)
20:40sfinkI think this sidestepped a heuristic for ignoring some things like this, instead exposing the actual type, which leads it to the PPLDHashTableOps.clearEntry false positive
20:40emiliosfink: it doesn&#39;t make a lot of sense to me, so I&#39;m not sure if it&#39;s some whitelisting that had to whitelist DynamicAtom and now whitelist nsIAtom, or a bug in the analysis, or something I should really look into
20:40sfinkit&#39;s a false positive (unless someone&#39;s doing something *really* weird with a PLDHashTable, which I doubt)
20:40sfinklet me see if I can figure out what it was using to ignore this before...
20:41emiliosfink: cool, thanks!
20:42bz ?
20:42sfinkoh, wow, I guess it assumes that nsISupports::Release never GCs
20:44sfinkso the straightforward options would be (1) extend that to nsIAtom::Release, or (2) whitelist PLDHashTableOps.clearEntry. I don&#39;t *think* it&#39;s likely that anyone would use a clearEntry that could GC, but I guess I&#39;m not sure.
20:46sfinkhm, the vast majority are pretty trivial (memset(0) or setting to nullptr), but isn&#39;t nothing.
20:46sfinkI guess it&#39;s not too bad
20:47sfinkit can run destructors, which is a little scary
20:48sfinkcan we replace PLDHashTable with something that uses virtual functions, please? :-)
20:48sfinkemilio: I&#39;d be fine with adding .clearEntry right after
20:49sfinkthough it might find something else it doesn&#39;t like
20:49emiliosfink: cool, will run a try run and get back if it doesn&#39;t work I guess, thanks! :)
22:06emiliosfink: no such luck:
22:07sfinkugh. I suppose moveEntry is probably just as safe.
22:08sfinkmaybe do a try push adding moveEntry as well, but then do a parallel push where you add in nsIAtom to line 152?
22:08sfinkreturn (csu == &quot;nsISupports&quot; || csu == &quot;nsIAtom&quot;) && (method == &quot;AddRef&quot; || method == &quot;Release&quot;)
22:11emiliosfink: k, will do
22:47RyanVMwow, so that&#39;s why hazard builds on autoland have been broken all day
22:47RyanVMand blocking any hopes of doing any merges from it
22:48RyanVMemilio: can we please backout for now?
22:49emilioRyanVM: hmmm... I&#39;d be fine with it, but you need to also back out the servo changes, which is annoying. I have two try runs already in progress, maybe if one of both works I can just land the patch?
22:50RyanVMi just merged the last rev before your push, so that&#39;ll probably have to suffice for now then
23:49jason___there seems to be an oversight in the api for defining functions and I&#39;d like to know what some alternatives are here
23:50jason___basically the function spec has no way to set an embedder pointer (reserved slot (EXTENDED))
23:51jason___that can only be done through an entirely separate surface in jsfriendapi
23:51jason___the DefineFunctionWithReserved() et al
23:52jason___the problem is that makes all the other ways to define functions useless
23:52jason___like InitClass()&#39;s array of JSFunctionSpec&#39;s
23:53jason___now that isn&#39;t useable because these two api surfaces meet up way too far up the stack internally
23:55jzkkkwhat i need is to recover classp from a JSFunctionSpec i passed to InitClass()
23:58jzkkkis there a way i can find it from a JSNative handler for a member function specified in InitClass()
10 Aug 2017
No messages
Last message: 12 days and 5 hours ago