mozilla :: #jsapi

17 Mar 2017
00:33terprican primitive values be allocated in the nursery? afaict it's currently only used for objects
00:33gkwglandium: hi! I have an update
00:34gkwglandium: I tested that switching to -gdwarf-2 *and* using gdb 7.12 (after going through many hoops on 10.7) works
00:36glandiumgkw: -gdwarf-2 doesn't work with the old gdb?
00:36Waldoterpri: most primitive values aren't gcthings at all, to be in the nursery *or* elsewhere
00:36gkwglandium: nope, the old gdb doesn't work with either
00:36Waldoterpri: off the top of my head, strings and symbols are the exceptions
00:37Waldoterpri: I think I might be surprised if strings can't be nursery-allocated, at a minimum, but I don't know for sure
00:37gkwglandium: I had to use homebrew to install on 10.7, generate a cert, codesign it (all of it a pain), run the shell with the testcase, then point to the -gdwarf-2 file
00:37gkwand this was on gdb 7.12
00:37gkwglandium: so this sounds like 2 bugs we can file:
00:37gkw(1) switch to -gdwarf-2
00:38gkw(2) swap out the js shell's DWARF file to be a separate zipfile instead of being in the ginormous *.crashreporter-symbols-full.zip
00:39glandiumgkw: (2') write a script that can download files off a zip with range requests
00:40glandium(assuming that doesn't exist)
00:40glandiumit'd be actually rather trivial
00:41gkwglandium: wouldn't the range change each time? The sizes of the DWARF files might vary
00:41glandiumgkw: zip files have a list of files at the end. download the end to read the list, where you get the offsets and sizes
00:42terpriWaldo, thanks, i'll investigate string allocation
00:42glandiumgkw: in fact, a file-like class that does http range requests should work with the zip/jar reader code we have in tree
00:44glandiumah no, it reads it all first
00:45glandiumgkw: I can trivially hook that up
00:46gkwglandium: sorry, which one of it can you hook up trivially?
00:46glandiumgkw: 2'
00:47gkwglandium: I see. I was thinking to do it in Python
00:47glandiumgkw: I was talking about the python zip/jar reader code
00:47gkwglandium: where is the python zip/jar reader code located?
00:48glandiumgkw: python/mozbuild/mozpack/mozjar.py ; I'm already on it anyways
00:48gkwglandium: cool, thanks
00:48gkwglandium: I'll update the bug to mention -gdwarf-2
01:33tcampbellLooks like ff went down on second pwn2own challenger
01:36glandiumgkw: https://pastebin.mozilla.org/8982291
01:38gkwglandium: woohoo! is that with current m-c tip unzip.py?
01:38glandiumgkw: there is no unzip.py yet
01:39gkwd'oh heh
01:39gkwhttps://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/
01:39gkwactually https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/action
01:39gkwglandium: that would be a great help, pls let me know if you need me to file a bug
01:39* gkw got distracted by other issues
01:40glandiumgkw: I'll file it when I have it actually do extractions too
01:40gkwglandium: perfect, thanks!
01:56gkwglandium: https://pastebin.mozilla.org/8982292 - lldb 10.12 stock dies w/ an assertion failure when trying to get a backtrace after a symbols file has been imported
02:01gkwglandium: I was able to stop the assertion failure by changing the build_src dir away, so no biggie
05:03* Waldo stabs TokenStream::reportCompileErrorNumberVA repeatedly
06:45Yoricstandups: Bug 1339568 - Intermittent shutdown hang in linux32/64 mochitest-media-e10s jobs - givin a hand
06:45standupsOk, submitted #43832 for https://www.standu.ps/user/Yoric/
06:45firebothttps://bugzil.la/1339568 REOPENED, gbrown@mozilla.com Intermittent shutdown hang in linux32/64 mochitest-media-e10s jobs
07:11Yoricstandups: #introduction mentoring
07:11standupsOk, submitted #43836 for https://www.standu.ps/user/Yoric/
08:49h4writerevilpie: ping
10:19Yoricstandups: Bug 1347711 - Refactor error reporting out of TokenStream - WIP
10:19standupsOk, submitted #43847 for https://www.standu.ps/user/Yoric/
10:19firebothttps://bugzil.la/1347711 NEW, dteller@mozilla.com Refactor error reporting out of TokenStream
11:11bbouvierhaha, i like that the pwn2own bug has been opened in the JS engine component by default :}
11:14h4writerbbouvier: yeah :P
12:09h4writerjandem: ping
12:10jandemh4writer: pong
12:10h4writerjandem: where do we stack overflow checks?
12:10jandemh4writer: you mean in JIT code?
12:11h4writerjandem: I'm looking at a stack overflow in C++ code that was called through EnterBaselineMethod
12:12h4writerasm -> DoToNumberFallback -> EnterBaselineMethod (failing here)
12:13jandemh4writer: in that case we should have checked for overrecursion in the JIT code prologue or in EnterBaselineMethod itself IIRC
12:15h4writerah. I think I found it in EnterBaseline
12:29h4writerjandem: how do we estimate the limit?
12:29jandemh4writer: is it in the shell?
12:29h4writeryes
12:31jandemh4writer: http://searchfox.org/mozilla-central/source/js/src/shell/js.cpp#137-141
12:34h4writerjandem: I got the test say we can go till: "0xffae3001", while the stack stops at "0xffb01000"
12:34h4writerthere must be a discrepancy somewhere
13:34bbouviersomebody to steal second review on bug 1346810, please? it's really an easy one (add a few calls to ReportOOM(cx))
13:34firebothttps://bugzil.la/1346810 ASSIGNED, bbouvier@mozilla.com Crash [@ js::jit::MBasicBlock::add] with OOM and asm.js
13:36bbouvieri can offer a local craft to the reviewer, next time i'll see them, or a multi-user license for Firefox, unlimited in time and usage
13:37* tcampbell takes a quick look to see if I understand it
13:48tcampbellbbouvier: I notice in other cases in the parser, there is a comment block https://searchfox.org/mozilla-central/source/js/src/frontend/Parser.cpp#883 around GC concerns for allocation. Any thoughts if this applies to the MakeUnique case?
13:51bbouviertcampbell: MakeUnique uses malloc, not the GC allocation, so we should be safe here
14:01tcampbellbbouvier: okay, I'm sold. r+
14:01bbouviersee also http://searchfox.org/mozilla-central/source/js/public/UniquePtr.h#48
14:01bbouviertcampbell: thanks!
15:21denisHi all. Is there any skill to help me use rr to debug GC rooting issues?
17:47jimbglandium: bug 1316518 mentions cppunittests.ini files, but I don't see any in the tree. Is that bug out of date?
17:47firebothttps://bugzil.la/1316518 NEW, nobody@mozilla.org Generate cppunittests.ini at build time
17:49jimbOh, testing/cppunittest.ini, no 's'
17:49jimbnm
18:23bzhrm
18:35tcampbelldjvj: oops. we messed up experiment. we loaded the address, but didn't fetch stub, let alone JitCode
18:42djvjtcampbell: ah..
18:42djvjtcampbell: right.
18:42djvjtcampbell: wanna try that? I think just loading the first word from the stub should be good
18:42tcampbellyep, firing it off
18:56sstanglI'm confused about the re-org, are we no longer under david bryant?
18:56sstanglit looks like we're now under dave camp?
18:57sstangloh, there's an attached doc that says that's the case. OK.
18:58tcampbelldjvj: splay is significant https://irccloud.mozilla.com/pastebin/lexjXp4V/
18:59shusstangl: huh so platform is more or less gone?
18:59sstanglshu: yeah there's no platform team as of this morning
18:59sfinkbz: "will be joining" the Runtime Team? Aren't you kinda already there, whatever name it had previously?
18:59shuhuh, so... huh
18:59sstanglsfink: "Platform" was broken up into two teams, "Runtime" and "Visuals"
18:59sfinkoh. I guess part of platform is now in Visuals?
18:59sfinkok
18:59shuwell, there's other stuff in there too
19:00shulike Password Manager
19:00shulol
19:00sstanglwell, Media I guess.
19:01sstanglI wonder if they've thought about what it means to say that a project is part of "Visuals". Front-end has tons of perf problems, but they're under "Visuals"; hopefully that doesn't change scope
19:03sstanglI'm now concerned that there are other ehsans
19:05bzsfink: sorta
19:05sfinkother ehsans?
19:05bzsfink: dbryant's direct reports got split across the runtime and visuals teams
19:06sstangland quantum-flow is just some agglomeration across the whole org-chart
19:10bzSure
19:10bzI mean, if you look at the org chart, the DOM module owner is on the visuals team
19:11bzWhich mostly comes down to some people having fingers in so many pies that it's impossible to slot them into an org chart that matches what they're actually responsible for.
19:11bzWhich means, take the org chart with a grain of salt.
19:11djvjtcampbell: is everything else noise or is it worse?
19:11bz(Or if NaCl is not your thing, a grain of webasm, I guess.)
19:11sfink./mach reorg engineers --num-chunks 3
19:11bzsfink: heh
20:48sfinkmccr8: ping
20:48mccr8sfink: pong
20:49sfinkmccr8: would it be bad if I made gcreason::COMPONENT_UTILS imply that we should discard jit code?
20:49mccr8sfink: Why do you want to do that?
20:50sfinkI'm running into a problem where a jetpack test expects that when you do SchedulePreciseGC or whatever it's called, that WeakReferences fire for things that aren't referenced
20:50sfinkand I'm adding in something in jitcode that hangs onto a wrapper, which breaks it
20:51sfinkmaybe COMPONENT_UTILS is too broad, but it does seem like a "precise GC" probably ought to be precise. Ish.
20:51sfinkmuch as I dislike anyone relying on that precision
20:53mccr8sfink: maybe try sending a memory pressure notification? Does that cause us to drop JIT code? https://github.com/MozillaSecurity/funfuzz/blob/master/dom/extension/content/fuzzPriv.js#L157
20:53sfinkwell, I think I could request a compacting GC
20:53sfinkI guess it's more a matter of what the semantics of a "precise GC" should be
20:54sfinkhttp://searchfox.org/mozilla-central/source/addon-sdk/source/test/test-disposable.js#288
20:55sfinkeg it looks like Promise tests use it
20:55sfinkand this leak-utils test
20:56sfinkthey aren't breaking currently, but if they happened to hit baseline, they might
20:56mccr8How often do we drop JIT code normally?
20:57sfinkI'm not entirely sure. But from the code, the main trigger seems to be a compacting GC.
20:58sfinkbut it's hard to tell from the code. Maybe I should instrument a browser, since I've always been curious about that exact question.
20:58mccr8I'm just a little concerned about how your change might increase memory usage, and then dropping JIT code with COMPONENT_UTILS might cause us to not notice in testing.
20:58mccr8but maybe that's not a realistic fear.
20:59sfinkif COMPONENT_UTILS is used for more than Cu.schedulePreciseGC, then I think it's the wrong thing.
20:59sfinkactually, the "default" seems to be to drop jit code on a GC, unless comp->lastAnimationTime + PRMJ_USEC_PER_SEC >= currentTime
21:00sfink...which maybe means, "we've animated within the last second"?
21:00mccr8component utils is also used for forceGC
21:00sfinkok. Then I don't want that.
21:00sfinkI'd rather modify schedulePreciseGC to either do a compacting GC, or set a reason specifically for this purpose.
21:01mccr8yeah I think that makes sense.
21:01sfinkthanks!
21:01sfink(now this had better fix it...)
21:01mccr8sorry I should have mentioned earlier that COMPONENT is used in a lot of places.
21:01sfinkI thought that might be the case, but decided to be lazy and ask rather than figure it out myself
21:02sfinkdo you happen to know if schedulePreciseGC is used in perf-sensitive stuff (even tests), such that slowing it down to a compaction would be bad?
21:02sfinksearchfox seems to show only tests
21:03sfinkand none of them smell very perf sensitive
21:03sfinkoh, wait. There's a schedulePreciseShrinkingGC already? Hm....
21:03mccr8I think it is only used in a few places
21:04mccr8hmm well, maybe. I don't remember what GC thing we use for bc mochitests.
21:04sfinkyeah, but its presence suggests that people *don't* expect a precise GC to be shrinking
21:04mccr8ah right the shrinking one might just work
21:05sfinkI think I'll use a reason
21:05sfinkno sense in needlessly angering the erahm; test_awsy_lite uses it. ;-)
21:07mccr8why can't you use the shrinking one? doesn't that drop JIT code?
21:07sfinkI could. But I'm still hung up on wanting something named "precise" to actually be precise.
21:08sfinkand I'm adding this new jitcode thing that holds onto stuff
21:08mccr8presumably it isn't scanned conservatively, though
21:09sfinkno, but from the point of view of JS code, it could hang onto something that is no longer referenced anywhere
21:10sfinkit's cached in jit code that will never run again
21:10sfinkand I have an existence proof that it could be a problem
21:10sfinkpartly the problem is that GC really shouldn't be observable
21:10sfinkbut we provide WeakReferences
21:11sfink(so it is)
22:04fitzgensfink: ping
22:04sfinkfitzgen: pong
22:05fitzgensfink: ... un ping ... sorry
22:06fitzgensfink: does libjs_static.a require also statically linking libmemory.a?
22:06fitzgenand libmemory_mozalloc.a?
22:06sfinkno clue. Never heard of libmemory.a
22:07sfinkbut the shell build seems to link libmozglue.a libmemory.a libeditline.a libjs_static.a
22:08fitzgensfink: I'm in that special place in hell where PLT references are getting resolved to 0x0 at runtime and static libraries that I'm asking to be linked aren't getting linked and yet there aren't ld failures when I reference their symbols...
22:11sfinkwow
22:12fitzgenthe annoying thing is that I had exactly this happen before, and I fixed it by linking libmozglue.a, but now that fix is failing...
22:34shusfink: hi
22:34sfinkshu: I didn't do it
22:35shusfink: so i wanna move source compression to be done by the shrinking GC
22:35shusfink: but i don't want the shrinking GC to enqueue *all* sources to be queued if there are too many
22:35shusfink: can you think of a way to compute an upper bound based on current memory pressure?
22:35sfinkit can be async, I hope?
22:35shusfink: it is off-thread, yeah
22:35shusfink: but even so id on't want to tie up a helper thread for a long time
22:36shus/to be queued/to be compressed
22:37sfinkI'm not sure we have much of a notion of memory pressure. We have memory pressure events, and frequency of GCs.
22:37shusfink: hmm
22:38sfinkand tuning parameters for heap sizes, I guess
22:38shusfink: how are the incremental slice budgets computed, and what units are they in?
22:38sfinkthey're 40ms, 10ms, or unlimited
22:38sfinkI think 10ms is used when animating
22:39shusfink: i see
22:39sfinkthe option to make them in units of object counts is there, but I think it might only be used for deterministic testing?
22:39shusfink: i suppose i can do it similarly with the helper thread
22:39shusfink: just budget some ms
22:40sfinkwhat is the cost of compressing too much, other than blocking for a long time?
22:40shusfink: it won't even block
22:40sfinkas in, if the thread checked in periodically to see if there's higher priority work to be done, what would be bad?
22:40shusfink: but it'll tie up a helper thread, which might cause issues with slowing down off-thread Ion compiles
22:40sfinkwell, "blocking" was the wrong word
22:40shusfink: if the thread checked in to see if there's higher priority work, i think nothing
22:40sfinkit just seems like this is a priority problem more than a rate limiting problem
22:40shusfink: yeah, you're right
22:41sfinkI mean, there's battery life and things
22:42shuinteresting
22:59gandalfshu: I added my slides to the agenda for next week's tc39. It should be smooth, but in case something goes wrong, can you take a look at them and lmk if you have any questions?
22:59gandalfhttps://github.com/tc39/agendas/blob/master/2017/03.md
22:59gandalfshu: https://docs.google.com/presentation/d/1ddnQB8oUYyv7qtsmRFgcsScAI4uHTj8z9z_cPJxlOe4/edit?usp=sharing
23:00shugandalf: i will next week, thanks
23:01gandalfnp!
23:01gandalfthank you :)
23:01shuwho knows bhackett's cooperating threads stuff?
23:01sfinkjonco did a bunch of reviews for it
23:02shui'm trying to get a JSContext to interrupt from offthread
23:02shuzone->group()->ownerContext().context() is real scary looking
23:04sfinkI guess you're not in a different zone group, you're just not on the zone group's main thread?
23:04shusfink: yeah
23:06sfinkuh, good luck with that
23:08shuthanks
23:58shusfink: is beginMarkPhase always on the main thread?
18 Mar 2017
No messages
   
Last message: 189 days and 7 hours ago