mozilla :: #jsapi

17 Apr 2017
15:45billmsfink: where are we meeting?
15:45sstanglsfink's vidyo room?
15:47djvjsorry, just a tad late.
15:47djvjbillm: sstangl: heading there now
16:21billmhttp://spark.apache.org/docs/latest/programming-guide.html
16:22billmhttp://spark.apache.org/docs/latest/programming-guide.html#working-with-key-value-pairs
16:51billmhttps://gist.github.com/bill-mccloskey/7d61e025c3c66f5fbfc19067fad941f7
17:12sfinkjs/src/devtools/gc-ubench/index.html
17:32mccr8sfink: sorry I was so late. I wasn't feeling well last night, and I was pretty out of it this morning, so I just forgot about the meeting.
17:32sstangldjvj: mccr8: (garbage collection handbook) http://bookfi.net/dl/2234924/5ccada
17:32sfinkmccr8: that's ok, it was mainly billm's demo of the analysis.telemetry.mozilla.org ipython setup.
17:33sfinkI don't know how much you know about it
17:33sfinkbut would it be useful to have something similar for CC data?
17:33mccr8ah, great.
17:33mccr8sfink: CC data in general is unfortunately way behind GC stuff. The CC is a lot simpler, is part of it.
17:34sfinkyeah, I wasn't sure if it was even useful to do. Might not be necessary.
17:34mccr8sfink: something like 90% of slow CC time tends to be spent in the "mark" phase.
17:35mccr8sfink: do we spend much time in foreground finalization? I feel like a lot of DOM stuff could be moved to background finalization. Maybe.
17:35mccr8most of the finalizers just shove stuff into a runnable anyway so no reason to do that on the main thread.
17:35sfinkif I could get this notebook thing to work for me, I could probably answer directly...
17:35mccr8WebIDL finalizers hopefully don't need to interact much with XPConnect. I could be wrong, though.
17:36sfinkbut I've had the same feeling. In general, I feel like foreground finalizers are a big deal.
17:37sfinkand for some things, we might be able to split out stuff that really really needs to happen in the foreground from stuff that can be backgrounded. So we'd have fg and bg finalizers for the same objects. I don't know enough about what those finalizers are doing to know how much it would apply.
17:48bzwebidl finalizers do interact with something, iirc
17:48* bz checks
17:49bzAddForDeferredFinalization
17:49bzIs the thing they do
17:49bzwhich uses TLS to find the thing to add to
17:49bzIt also writes to the backing DOM object to clear its cached value (since that value is dying)
17:50bz(things without a wrapper cache do not have that write, but do still have the AddForDeferredFinalization bit)
17:50bzsfink, mccr8: ^
17:50sfinkhm, ok
17:52sfinkthe wrapper cache clearing sounds like it needs to be foreground. If the GC managed the deferring, would it need the TLS part? Or could the GC just call its (deferred) finalization stuff directly, from the bg GC finalizer thread?
17:52sfinksorry, the 1st sentence is separate from the 2nd two
17:55mccr8ah right I forgot about the cache clearing.
17:55mccr8sfink: well, you could add a TLS thing for the GC thread. then dispatch it back to the main thread.
17:56sfinkoh, "deferred" != "offthread"?
17:56mccr8I guess things have to have a static finalization kind so maybe there's not too much mileage to be gotten out of it.
17:57mccr8sfink: it just stuffs the reference into an array so that it can be Released() after the GC is over.
17:57sfinkmccr8: and Release() needs to run on the main thread?
17:57mccr8sfink: yes
17:58djvjI can understand Release() being on the main thread, but the underlying free() doesn't have to be, no?
17:59djvjalso, we should look into why we free jitcode syncrhonously during GC..
17:59mccr8We run deferred finalization incrementally so it shouldn't be a big deal for pauses.
17:59sfinkdjvj: discardJitCode does a lot more than just freeing the jitcode
17:59djvjif we're collecting it, it must be guaranteed that it's never going to be executed again. Whatever bookkeeping we need to do with the jitcode can be done when it's mapped read-only
17:59sfinkand in fact, that part has to be deferred to the following minor gc
17:59djvjer, exec-only
17:59mccr8Deferred finalization is another thing we'd schedule in a single location in a perfect world. ;)
18:00sfinkthere are cached and references and things that have pointers into the stuff you're discarding
18:00sfinkhttp://searchfox.org/mozilla-central/source/js/src/gc/Zone.cpp#192
18:00djvjsfink: those can all be unlinked without doing the mprotect/free
18:01sfinkI'm not sure when the mprotect happens. I think the main free is already deferred.
18:02sfinkyou probably understand what all is going on in that function better than I do
18:03bzdjvj: the underlying free() does not need to be on the main thread, but the C++ destructor does.
18:04sfinkwe used to have a background free() thread for all js_malloc'ed stuff, but I think we stopped doing that at some point when it wasn't helping
18:04* bz seems to have vague memories of it not helping much to do that on different threads because it just caused allocator lock contention or something
18:04bzMaybe I'm thinking of the thing sfink is thinking of....
18:06sfinkdarn, can't find the bug. Bug 1052796 says "Now that the background free machinery is gone..." from 3 years ago.
18:06firebothttps://bugzil.la/1052796 NEW, nobody@mozilla.org Remove FreeOp
18:06sfinkwe still do background frees for nursery chunks
18:10djvjew, so JitCode::release just decrefs an executable pool, which frees() itself when refcount drops to zero.
18:10* bz is not sure how often we actually free nursery chunks
18:21ptomato-Mare there any plans yet for a standalone release of spidermonkey 52 for embedders?
18:22ptomato-MI would be happy to help out by e.g. building a release candidate
18:22ptomato-Mand identifying any issues that interfere with using it standalone
18:28sfinkptomato-M: could you check out an autobuilt one? eg https://queue.taskcluster.net/v1/task/VThzfjdsTFejAX4mli1LwQ/runs/0/artifacts/public/build/mozjs-53.0.0.tar.bz2
18:28ptomato-Mcertainly
18:29ptomato-Mis there a UI for that build system?
18:29sfinkhttps://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=d345b657d381ade5195f1521313ac651618f54a2&filter-searchStr=pkg
18:29sfinkI don't know if you want the filter
18:30sfinkhttps://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=d345b657d381ade5195f1521313ac651618f54a2 will give you the full wall of jobs
18:30sfinkbut in the that first link, you can click on pkg, then find the link in the Job Details pane at the bottom
18:31sfinkuse https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&filter-searchStr=pkg to find the latest build
18:32RyanVMptomato-M: sfink: FWIW, we do the same for esr52
18:32RyanVMi.e. https://queue.taskcluster.net/v1/task/MQSQnl1WT9WV9M8oL1vSAQ/runs/0/artifacts/public/build/mozjs-52.1.0.tar.bz2
18:32sfinkoh, right, that would make much more sense than the release channel
18:32sfinkthanks
18:32RyanVM^ is highly likely to be in line with the final 52.1 release
18:32ptomato-Myeah, was just poking around trying to discover that :-)
18:33ptomato-Mis this where to look? https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52
18:34RyanVMyes
18:34RyanVMunfortunately, correlating that exactly to a "final" release can be a bit of a pain
18:35RyanVMmaybe easiest to just grab the most recent SM pkg on release day
18:37ptomato-Mthere's no officially released package though right now, right?
18:37sfinkcorret
18:37sfinkcorrect
18:37sfinkother than missing release notes, there's no reason *not* to use the above as an official release
18:37sfinkbut nobody has checked it out
18:38ptomato-Moh, I see what you mean
18:38ptomato-Mwell, I'd be happy to check it out
18:38sfinkcool!!
18:38ptomato-Mare those links for downloading the packages permanent? or do they expire after some time
18:39sfinkthey'll expire. Not sure about how long they last.
18:39tcampbellI think on the order of 1 month
18:39* bz assumes absolutely nothing about our infra is permanent, because not breaking links is just not a priority for the people maintaining it....
18:39sfinkthe past releases have come from Very Official URLs like https://people.mozilla.org/~stangl/... :-)
18:39sfinker, ~sstangl
18:39ptomato-M:-)
18:40ptomato-MI was wondering about that
18:40ptomato-Mthey used to go here http://ftp.mozilla.org/pub/js/
18:43evilpiewe should just hassle releng to build every ESR spidermonkey version for us
18:43evilpieand put it there
18:46sstanglI used to have FTP access, but we switched to S3 and I wasn't able to find out how to host files there
18:56sfinkfwiw, https://index.taskcluster.net/v1/task/gecko.v2.mozilla-esr52.latest.firefox.sm-package-opt/artifacts/public/build/mozjs-52.1.0.tar.bz2 goes to the latest build
18:57sfinkwhich is less useful than it could be, given the version string embedded in there
18:58jorendorffhey everyone: if you ever run across a real-world profile where CCWs are implicated, please ping me
19:03jorendorffI believe it's a real problem for chrome code, but I still haven't seen a client case, even with Google Sheets which was supposed to be the smoking gun
19:48evilpieehsan: interesting those slides mention for .. in
19:49evilpieI have just been thinking about how we need to totally modernize this
19:51djvjevilpie: go on
19:52djvjevilpie: modernize in what way? how can we improve?
19:54evilpiewe need to optimize it for iterating over arrays
19:55evilpiehttp://searchfox.org/mozilla-central/source/js/src/jsiter.h#33 and this
19:55evilpieoh and maybe look into how others look up the matching iterator for an object
19:55evilpiemaybe instead of a global cache we could put it on a shape?
19:56djvjevilpie: we use a global cache? isn't the iterator lookup obj[Symbol.iterator], which would naturally be a shape-based lookup..
19:56evilpiethis is about for .. in!
19:57evilpienot the new Symbol.iterator protocol for "for .. of"
19:57evilpiewe can basically use whatever we want
19:57djvjevilpie: ah.. k
19:57evilpiein theory our implementation doesn't even match the spec, but I need to figure out the differences
19:59ehsanevilpie: yeah, I also like how simple their whole approach is
19:59djvjevilpie: even if keep the current global cache, we should be able to "IC" the cache lookup off of a shape guard, no? Objects won't change their iterator type without changing their shape, I'm pretty sure..
20:02evilpiedjvj: yes good idea
20:02evilpieShould be pretty easy
20:02evilpieWe just need to figure out something better for dense elements, because they aren't captured by the shape
20:04djvjevilpie: are those a common case?
20:04evilpiedjvj: yeah, at least jquery has it
20:05evilpiebug 1344469 has something about this
20:05firebothttps://bugzil.la/1344469 FIXED, evilpies@gmail.com Optimize Object.hasOwnProperty
20:05djvjI still don't see why we can't use shape for that. If we confirm that obj X has shape S and is an array, and we guard on shape S later, that should be enough to infer that the new obj Y is an array
20:10evilpiedjvj: we actually cache a list of property names
20:10evilpiedjvj: but adding a new integer property to dense elements isn't detectable in that way
20:11evilpieI think v8 just dynamically adds the integer properties when looking up the iterator for an object
20:46jimbh4writer: ping
21:24shuhow do i symbolicate ASAN stacks?
21:24shuis there some nice flag?
21:32sfinkThis is running locally? I probably ought to have an answer for you, since I've done it. Does tools/rb/fix_*_stack.py do it?
21:32sfinkshu: ^
21:33sfinkoh, wait. You probably have to give it the llvm_symbolicator thing
21:33shusfink: i mean i can just take all the addresses and manually run them through atos or whatever
21:34shusfink: wondering if there was a flag so it just does it during printing
21:34sfinkmaybe set LLVM_SYMBOLIZER to .../clang/bin/llvm-symbolizer
21:34shuah ha
21:35sfinkfor msan, I use MSAN_OPTIONS with external_symbolizer_path=... but for asan and tsan I use LLVM_SYMBOLIZER
21:35sfinkI don't remember what the whole story was
21:35shusfink: thanks
21:35sfinkffr, see js/src/devtools/automation/variants/{asan,msan,tsan}
21:35shuffr?
21:35sfinkfor future reference
21:36sfinkjust made it up and hoped it meant something :)
21:36shuah
22:02sstanglnaveed: pingu
22:02naveedsstangl: pongu in my room when you are ready
22:29shupingu is a terrifying show
22:29shuoh no where did sfink go
22:40Waldowherever sfinks go
22:40* Waldo looks around furtively for crossbows
23:06shumrgiggles: can GetSrcNote gc
23:06mrgigglesshu: No, nothing matching |GetSrcNote| can GC. Matches are: _ZN2js10GetSrcNoteEP9JSContextP8JSScriptPh$uint8* js::GetSrcNote(JSContext*, JSScript*, uint8*)
23:06mrgiggles_ZN2js10GetSrcNoteERNS_8GSNCacheEP8JSScriptPh$uint8* js::GetSrcNote(js::GSNCache*, JSScript*, uint8*)
23:27shubillm: ping
23:27billmshu: pong
23:28shubillm: mysteriously, making DeadObjectProxies unconditionally is-callable and is-constructor makes some recompute wrapper test fail
23:28shubillm: i don't feel like investigating so i'll just do the template thing
23:28billmshu: ok, that sounds fine
18 Apr 2017
No messages
   
Last message: 12 days and 8 hours ago