mozilla :: #jsapi

16 Mar 2017
00:19gkwglandium: unfortunately I get an error:
00:19gkwcan't read symbols: File format not recognized.
00:22gkwglandium: tested on Mac OS X 10.7 which has gdb (the loaner machine I was given is 10.7, and the releng machines' OS (whose spare time I will use) is 10.7)
00:22* gkw can't remember when it changed to lldb
00:28smaugntim: pong
00:30glandiumgkw: you want the .dbg file
00:32gkwglandium: the file only has *.sym files
00:32gkwlet me try with the full file
00:34gkwglandium: nope, the full file only has the *.sym files and DWARF stuff
00:35glandiumgkw: that's what you want, the dwarf stuff
00:36glandiumon mac, they might be called .dSYM
00:38gkwglandium: no such luck:
00:40ntimsmaug: Hey! I&#39;m planning to work on making <iframe mozbrowser> available for moz-extension:// documents, what approach would you suggest for checking when mozbrowser should be enabled ?
00:40smaugI have no idea what moz-extension:// implies
00:41glandiumgkw: you wouldn&#39;t get anything different with non-stripped js, since it would have the same dwarf
00:41ntimsmaug: web extension documents
00:41smaugwhat does that mean?
00:41smaugwhich principal do they use?
00:41gkwglandium: in non-stripped js I don&#39;t even have to access the dwarf to get the function names on the stack
00:41smaugwhat is the origin for those documents?
00:41smaugwhat kind of privileges do those documents have?
00:42smaugI&#39;m just not at all familiar with moz-extension
00:42gkwglandium: I had a releng shell from a few days ago, tested with a testcase, then repeated the test with a freshly downloaded latest one to get the differences in output in:
00:43firebotBug 1347750 NEW, Having a stripped js shell breaks fuzzing on releng js shells that we ship
00:44smaugntim: I think you need to ask bholley or bz, based on the blame
00:45glandiumgkw: point is, those dwarf errors, you would get them just as well if the js shell was not stripped
00:45glandiumgkw: or there&#39;s a bug in gdb
00:46ntimsmaug: all webextension add-ons have their HTML pages under moz-extension://
00:46glandiumgkw: you can try stripping that js binary you got from before, and download the separate dwarf symbols corresponding to it
00:46gkwglandium: yes, I get that. What I meant was that I could get function names with a non-stripped binary (notwithstanding whether a dwarf file is needed)
00:46ntimsmaug: moz-extension:// has normal content privilege + access to the browser.* APIs
00:46gkwglandium: now with a stripped binary, I just need to get the symbol-file working, which I&#39;m unable to
00:46ntimsmaug: but it doesn&#39;t have chrome privilege
00:47gkwglandium: I&#39;m fixed with the gdb version in Mac OS X 10.7
00:47gkwGNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011)
00:47glandiumgkw: can&#39;t use lldb?
00:47smaugntim: ok, so extend the permission checks we have for mozbrowser?
00:47gkwglandium: I also redownloaded a stripped binary from that same directory as the symbols but didn&#39;t work either
00:48ntimsmaug: yeah, this is what I want to do
00:48gkwglandium: lldb does not exist on stock 10.7
00:48ntimsmaug: I want to allow mozbrowser to be used for moz-extension:// HTML files, but not allow <iframe mozbrowser> to be injected via webextension content script
00:49glandiumgkw: download a non-stripped binary, strip it, and download the separate symbols that correspond to it. If /that/ doesn&#39;t work then that means there&#39;s a problem with gdb
00:49glandiumgkw: if that works, then there&#39;s a separate problem with the dwarf in recent builds
00:49gkwglandium: will try that
00:49smaugntim: then check the original document uri around ?
00:50smaugand probably also somewhere in nsFrameLoader
00:51ntimsmaug: I suspect I need to change this as well:
00:51smaugntim: perhaps not document uri, but principal... not sure, since I&#39;m not familiar with what kind of principal moz-extension documents get
00:52smaugntim: oh, sure, perhaps Pref=&quot;dom.mozBrowserFramesEnabled&quot; stuff? That would become Func=&quot;SomeCheck&quot;
00:52ntimsmaug: there&#39;s bug 1310318 about exposing a chrome API to webextension, but it seems it exposes that API to content scripts as well, and I definitively do not want to allow webextensions to be able to inject <iframe mozbrowser> everywhere via content scripts
00:53firebot FIXED, content script access to canvas.drawWindow
00:53smaugntim: what you mean with &quot;content scripts&quot; in this context?
00:53* smaug reads the bug
00:54smaugah, I see
00:54ntimsmaug: Basically, content scripts are scripts that extensions can inject in any webpage:
00:55smaugntim: right, so in you would check whether the _document_ has right principal
00:55smaugnot caller
00:55ntimsmaug: do I have access to the document with Func=&quot;SomeCheck&quot; ?
00:56ntimAFAIK, you only get the JSContext
00:56smaugntim: FWIW, some people used word &quot;content script&quot; as a synonym to frame script at some point, and for some any &quot;content&quot; means web page
00:56smaugget where?
00:56smaugthe link I gave does nothing with JSContext
00:56smaugyou have an element.
00:56ntimsmaug: for the webidl
00:57smaugah, that
00:58ntimYou only get a JSContext and a JSObject
00:58smaughmm, so you conditionally have different prototype objects per global
00:58smaugI&#39;m not sure that is supported
00:59smaughow would that even work
00:59smaugsounds like you need different prototype object for mozbrowser in moz-extension documents and then normal iframe for other documents
01:00gkwglandium: no such luck either. DWARF files don&#39;t work with the unstripped binaries either
01:01smaugntim: and then in return different value based on the owner document
01:01gkwglandium: shall I file a separate bug?
01:01glandiumgkw: try a newer gdb
01:01glandiumor lldb
01:03ntimsmaug: I might also be wrong about the assumption that enabling it for all add-on principals will allow content scripts to inject <iframe mozbrowser>
01:03smaugntim: of course, what prevents one to move mozbrowser from moz-extension document to a web page...
01:04glandiumgkw: try a newer gdb, or lldb, or do a try build changing -g to -gdwarf-2
01:10ntimsmaug: there&#39;s xray vision that may be useful for this case ?
01:10smaugnot sure how that would help
01:12smaugbest would be to prevent moving mozbrowser to web pages
01:12smaugjust throw from insertBefore/appendChild or so
01:12smaugor something like that
01:12gkwglandium: trying with gdb 7.12 (via homebrew)
01:13ntimsmaug: you can&#39;t actually move elements from extension pages to web pages
01:13smaugwhat prevents that?
01:14smaugbut sounds good :)
01:14ntimsmaug: WebExtensions are designed so add-ons run in their own process
01:14smaugok, then good
01:14* smaug has no idea the status of webextensions
01:15ntimsmaug: I&#39;m just worried about the case where a content script might do:
01:15ntimlet i = document.createElement(&quot;iframe&quot;); i.setAttribute(&quot;mozbrowser&quot;); document.body.appendChild(i)
01:15smaugwell, that doesn&#39;t do anything per the link I gave
01:16smaugthe attribute just doesn&#39;t affect at all to the behavior
01:16smaugassuming ownerdoc&#39;s principal check is added there or something like that
01:17* ntim gets into more paranoia thinking about possible edge cases
01:17smaugwell, there is the existing mozbrowser which is exposed only pages with right permissions
01:17smaugthis isn&#39;t much different to that
01:19ntimsmaug: so the ChromeOnly flag is only for extra safety ?
01:20ntimsmaug: since you can&#39;t inject mozbrowser iframes into web content, I don&#39;t see how you can have access to the BrowserElement prototype in web content
01:21* smaug needs to read Pref=&quot;dom.mozBrowserFramesEnabled&quot; + ChromeOnly handling
01:21smaugis it && or ||
01:22smaug&quot;If more than one of these is specified, all conditions will need to test true for the interface or interface member to be exposed.&quot;
01:23ntimso it&#39;s &&
01:24gkwglandium: still having difficulty running gdb 7.12 via homebrew. lldb isn&#39;t available via, so trying taps. Which file should I change if I were to do the try build?
01:24smaugbut I guess you&#39;ll change it to just Func=&quot;..&quot;
01:24smaugntim: or do we need some new interface ?
01:24smaugto be compatible with other browsers
01:24ntimsmaug: I don&#39;t think we do
01:25glandiumgkw: default_debug_flags in build/moz.configure/toolchain.configure
01:26ntimsmaug: So in the function, checking for the principal to be add-on related is enough right ?
01:27ntimI guess there&#39;s no need for the document check since the mReallyIsBrowser thing takes care of that
01:29smaugntim: so, can moz-extension privileged JS run in web page?
01:29smaugI assume so
01:30ntimsmaug: yes, via content scripts
01:30smaugbut those are in child process
01:30smaugnot in extension process, right?
01:30ntimsmaug: well, they have a limited access to the extension APIs
01:31smaugthat does explain in which process they run
01:32ntimsmaug: it&#39;s in the child process yes
01:33smaugntim: ok, so then we don&#39;t want to get mozbrowser &quot;view&quot; of an iframe
01:34ntimsmaug: what do you mean?
01:35smaugntim: content script shouldn&#39;t get a prototype object for web page&#39;s iframes with all the mozbrowser specific methods
01:35smaugso, perhaps Funct=&quot;&quot; should also check the process
01:35smaugand if not in extension process, return false
01:36smaugwhat is the expectations for using <iframe> and <iframe mozbrowser> in same moz-extension document (in extension process)? should they both have the same prototypes?
01:39ntimATM, the extension process is just the content process, but that&#39;s expected to change soon
01:39ntimthe parent process*
01:39smaugntim: ahaa, so in case e10s isn&#39;t enabled, extensions do run in the same process as web pages
01:41ntimsmaug: iframe should behave like a content iframe, iframe mozbrowser should behave like a chrome iframe mozbrowser
01:41smaugjust thinking about which methods the prototype should have
01:43ntimsmaug: I&#39;m planning to support the P1 to P3 APIs from this list:
01:43ntimsmaug: for <iframe mozbrowser>
01:45smaugntim: sure, but is it expected that the same methods are visible also with <iframe>, even if not doing anything
01:45ntimsmaug: no
01:46smaugsince if not, then we need separate proto. (though, creating mozbrowser would be hard. not possibly using createElement + setAttribute)
01:48ntimsmaug: the BrowserElement methods and the normal iframe methods live in different webidls, so I&#39;m assuming they get &quot;assigned&quot; to the prototype differently ?
01:49smaugntim: the prototype is just created once
01:49smaugper global or so
01:50ntimsmaug: my assumption is that the methods from the BrowserElement are only present with GetReallyIsBrowser is true
01:50ntimsmaug: let me check using some manual testing
01:51ntimsmaug: considering <iframe mozbrowser> was originally designed for Firefox OS, I don&#39;t expect it to leak methods to <iframe> under the same document
01:52smaugnot sure about that
01:52smaugbased on the webidl, the methods are all there, unless we have some magic somewhere I&#39;m not familiar with
01:53smaugbased on testing the methods are there
01:54smaugwhen chrome JS accesses any web page <iframe>
01:57ntimsmaug: ah yeah, they seem to be there
01:58ntimsmaug: they seem to be there, but they just throw when you call them on normal iframes
01:58smaugand I wonder if that is acceptable
01:59smaugor whether something else is needed for extensions
01:59ntimI think this is acceptable
01:59smaug(getting late here)
01:59ntimsmaug: provided that we show a better error than &quot;InvalidNodeTypeError: The supplied node is incorrect or has an incorrect ancestor for this operation.&quot;
02:00ntimsmaug: 2am at my place :)
02:00smaug4am here
02:00smaugbut yeah, better exceptions should be easy
02:01smaugbut now, good night
02:01ntimsmaug: good night
02:02ntimsmaug: thanks for your help
08:27jandembz: pong
09:29Yoricstandups: Bug 1347861 - Consider storing hints during syntax parse - filed
09:29standupsOk, submitted #43790 for
09:29firebot NEW, Consider storing hints during syntax parse
10:53zombieis there an easy way to spin the event loop in JS?
10:56zombie(trying to replicate a race condition reliably, which may depend on a js script taking long to parse/execute)
12:19jdmzombie: sync XHR? alert?
12:26zombieright! i guess there&#39;s a reason i blocked sync xhr out of memory
12:35smaugnbp: did you ever find time to write a helper for the Add*VarCache stuff?
12:36nbpsmaug: I started, but I did not continue as I had other priorities.
12:36smaugjust asking since I&#39;m reviewing code adding more AddBoolVarCache usage
14:03ntimsmaug: ping
14:03smaugntim: pong
14:04ntimsmaug: Hi! Hope you had a great sleep :) Which principal does NodePrincipal() correspond to here ?
14:05smaugntim: NodePrincipal() is the principal of the owner document
14:05ntimsmaug: thanks
14:05smaugntim: so perhaps that check is enough for your case
14:05smaugsince web pages should never have the permission to allow mozbrowser
14:06smaug(but you need to allow the permission on moz-extension principals)
14:06ntimsmaug: this is the code I&#39;ve added:
14:07ntimwhere principal is NodePrincipal()
14:07smaugI thought we&#39;re removing addonId
14:08smaugoh, hmm, only from originattributes
14:23ntimsmaug: Should the function specified in [Pref=&quot;&quot;] be on a particular class ?
14:23ntimsmaug: I&#39;ve added it to nsGenericHTMLFrameElement, but I have a feeling that&#39;s not right
14:23smaugdoesn&#39;t really matter
14:24smaugyou mean Func
14:24ntimsmaug: yes, Func
14:24smaugdoesn&#39;t really matter, but bindings layer needs to find it
15:01ntimFeels great to see &quot;XUL&quot; when doing a full build
15:08bzIs AutoCheckCannotGC just a runtime check, or does it affect the static analysis?
15:29* bz reads the comments, gets his question answered
15:29ntimsmaug: interesting, a webextension document opened in a tab has a content principal, not an extension principal
15:30ntimsmaug: if the same document is opened in the sidebar, using the sidebar API, then it has a extension principal
15:44ntimsmaug: actually, it works fine, the principal is correct, but for some reason the mozbrowser iframe is still restricted by CSP
15:56ntimsmaug: actually I seem to have a mozbrowser iframe that refuses to load any website
15:56ntimsmaug: I&#39;m thinking I&#39;m forgetting something in nsFrameLoader.cpp
15:58smaughard to say :)
16:01ntimsmaug: interesting, setting remote=&quot;true&quot; in addition to mozbrowser makes the iframe work again
16:01smauginside a tab?
16:01ntimsmaug: yeah
16:02smaugis the tab not remote itself?
16:02ntimsmaug: no, moz-extension:// tabs are loaded in the parent process
16:02ntimsmaug: but maybe moz-extension:// URIs loaded in the sidebar are in the child process
16:03ntimsmaug: I feel like remote=&quot;true&quot; should be default once you specify mozbrowser anyways
16:04smaugbut remote=true in sidbar might not work so well
16:04smaugsince it would create third process
16:05tcampbelljandem: I&#39;ve opened followup bug. I was just getting myself confused with doing bounds checks in Ion, so I&#39;m just landing the basic version for now.
16:05ntimsmaug: I don&#39;t think extensions should be able to set the remote or noisolation attributes anyway
16:06ntimsmaug: so I guess we should decide on sensible defaults
16:06jandemtcampbell: ok, note that Baseline uses an IC for this so it will be faster than the Ion VM call
16:07tcampbelljandem: ah, good to know
16:07ntimsmaug: FYI, the Firefox responsive design mode uses remote=&quot;true&quot; and noisolation=&quot;true&quot; so assume those defaults work well ?
16:08smaugntim: default in which cases?
16:08smaugremote=true is probably wrong when you are already in child process
16:08smaugremote=true is probably right when you are in parent process
16:10ntimsmaug: when you&#39;re in the parent process
16:10ntimI don&#39;t know how remote=&quot;true&quot; works exactly to be honest
16:10smaugremote=true tries to load the contents of the iframe in a separate process
16:11smaugso, if you are already in child process, it tries to create nested child process
16:11smaugwhich may or may not work well enough
16:12ntimsmaug: hmm, I think the sidebar case might be in the parent process actually
16:13tcampbelljandem: will take another pass at it. Didn&#39;t realize Baseline had an IC
16:14ntimsmaug: is there a way to check that ?
16:15ntimsmaug: what I currently do is check if the devtools can inspect the iframe contents
16:15ntimfrom the browser toolbox
16:15jandemtcampbell: cool, your patch is probably fine for now as a first step. I think Baseline uses the setelem IC but it would be good to try to refactor the initelem from the add/boundscheck
16:15smaugntim: silly way is to check if window.showModalDialog is available
16:15smaugshowModalDialog isn&#39;t available in e10s contexts
16:15jandemtcampbell: s/refactor/split/
16:16ntimsmaug: it is available for the sidebar case, which means it&#39;s in the parent process
16:17ntimsmaug: I wonder what makes it different from the tab case though :?
16:18smaugntim: I assume you&#39;re running debug build and don&#39;t see any suspicious warning
16:18ntimsmaug: currently in an opt build
16:19tcampbelljandem: thanks for feedback. Most of what I&#39;m trying to solve is getting all this half working code off my computer and get input from others . :)
16:20jandemtcampbell: makes sense. Great to see these ES6 features getting Ion support finally
16:24ntimsmaug: do I do ac_add_options --enable-debug-symbols ?
16:24smaugjust normal debug build
16:24smaugac_add_options --enable-debug
16:41bzdid we ever come up with a plausible defense for the &quot;getter on global lets you see whether a script touches that bareword&quot; scenario?
16:51bzAre there early errors that are not SyntaxError?
16:55ntimsmaug: I expected debug builds to be faster (in build time) than opt builds, but that&#39;s apparently not the case
16:55ntimit&#39;s still building atm
16:56ntim(this is my first debug build)
16:56smaugwe have lots of more code in debug builds
16:56ntimI originally thought optimizations would take more time to do
16:58sfinkthey&#39;re somewhat orthogonal. you can have debug+opt, nondebug+nonopt, or any combo
16:58bzsfink: did you see my response on the nsISupports thing?
16:59sfinkbz: I did, thanks. What does [noscript] mean, again? I always mix it up with [builtinclass]. Is [noscript] not callable from script?
16:59bzsfink: [noscript] means not callable from script, not implementable by JS.
16:59sfinkoh, both
17:00bzsfink: And applies to methods/properties, not the whole interface.
17:00bzsfink: an entire interface, has three valid states, basically, [], [scriptable,builtinclass], [scriptable]
17:00sfinkok. So I need to stare at a callgraph of a non-builtinclass non-noscript method.
17:00bzsfink: [] is not usable from JS and not implementable in JS.
17:00bzsfink: [scriptable,builtinclass] is usable from JS but not implementable in JS.
17:01bzsfink: [scriptable] can be implemented in JS and used from JS.
17:01bzsfink: Right, so for purposes of our analysis, we know a method is safe if either that method is [noscript] or the interface itself if not scriptable or the interface is [builtinclass]
17:01bz&quot;safe&quot; in the sense that just analyzing the overrides of that method in our tree is enough.
17:01sfinkhow is the scriptability implemented, though?
17:02bzWhat do you mean?
17:02ntimsmaug: hmm, fatal errors in code I didn&#39;t even touch with debug builds :/
17:02sfinkas in, is it visible to the thing that finds all virtual implementations?
17:03smaugntim: what kind of errors?
17:03bzsfink: probably not. :(
17:03bzsfink: It&#39;s available from our xpt files....
17:03sfinkok. Hm. The analysis does not currently know the attributes of interfaces or methods. Ugh.
17:03bzsfink: so we could do something with that, perhaps
17:04bzsfink: i.e. generate some data that the analysis then considers...
17:04sfinkif we could set some __attribute__ thing, I could get it from there
17:04bzThat seems totally doable
17:04bzAs in, we could hae a &quot;can be JS-implemented&quot; __attribute__ thing
17:05sfinkat the moment, it would have to be done via a macro that disables itself when not doing the analysis, because unknown attributes are -Werror&#39;ed
17:05sfinkwhich is a little annoying
17:05sfinkbut it&#39;s what I already do for the JS_HAZ_GC stuff
17:06froydnjwe already do that for all the static analysis attributes anyway
17:11bzsfink: file a bug?
17:12sfinkyeah, I&#39;m filing 2. What component is the IDL attribute stuff?
17:14sfinkCore :: XPCOM I guess
17:19mrgigglesthe mozilla-inbound tree is now closed (Build bustage)
17:25ntimsmaug: the same opt build worked just fine
17:26bzntim: you switched from opt to debug
17:26bzntim: without clobbering
17:27ntimbz: ah yes
17:27bzntim: &quot;don&#39;t do that&quot;
17:27ntimbz: thanks
17:27firebotBug 1293516 NEW, WebIDL build failures when switching build between opt and debug
17:27bzis what you hit
17:28mrgigglesthe mozilla-inbound tree is now open
17:32bzsfink: so would it be enough if I just annotated all the relevant things with JS_HAZ_GC_CALL ?
17:33bz(hypothetically speaking, if I were annotating it)
17:33bzsfink: or would we want a different annnotation?
17:33sfinkbz: for the hazard analysis? Yes. For mccr8&#39;s analysis? ...probably
17:34bzWhat&#39;s mccr8&#39;s analysis?
17:34sfinklet me find the bug
17:35sfinkbug 1249686
17:35firebotBug is not accessible
17:36sfinkso yeah, I think it&#39;s the same
17:37h4writerevilpie: ping
17:39sfinkI&#39;ve had vague ideas about distinguishing &quot;can run script&quot; from &quot;can GC&quot;, for other analyses
17:40evilpieh4writer: hi
17:42bzsfink: I can just add another annotation
17:43sfinkyeah, I think I&#39;d prefer that
17:43sfinkmccr8: pin
17:43sfinkmccr8: ping
17:45bzsfink: I assume you only need this decl on the actual pure virtual annotation?
17:45bzer, declaration
17:45bzsfink: not on the things NS_DECL_* generates?
17:46sfinkoh. err... let&#39;s see, I have a limited number of places I can gather attributes from. But I&#39;m pretty sure that&#39;s one.
17:47* bz pokes some more
17:47bzI&#39;m so glad this stuff is python now, not C
17:47sfinkI&#39;m looking for some samples of existing attributes to see what I get
18:04djvjsstangl: ping
18:04mccr8sfink: pong
18:05djvjsfink: hey, I wanted to chat with you and jonco at some point
18:05djvjsfink: do you think you&#39;ll have time this week for a 1-hour vidyo?
18:05sfinkmccr8: looking at the added overhead from bug 1335751
18:05firebot FIXED, Check gray mark state before cycle collection
18:05sfinkdjvj: jonco is on PTO until next week
18:06sstangldjvj: pong
18:06djvjsfink: don&#39;t need to speak with you two together.. individually is fine.
18:06sstangllike a principal&#39;s office
18:06djvjsstangl: hey, had questions about hte vtune integration
18:06sfinkmccr8: both s::CheckGrayMarkingState(mJSContext) and heckWeakMappingGrayBitsTracer::Check(mJSContext) are expensive, I guess?
18:06djvjsstangl: I built gecko with --enable-vtune
18:06sstangldjvj: it&#39;s enabled by default on nightly
18:06djvjsstangl: using trial version of vtune for windows to analyze it.
18:06sfinkmccr8: do you think it&#39;d be ok to skip all of CheckGrayBits on Android debug?
18:07mccr8sfink: what else is there to skip?
18:07djvjsstangl: I&#39;m still seeing most retired instructions being classified under &quot;Outside any known module&quot;
18:07sstangldjvj: and then it crashed all over the place, right?
18:07djvjsstangl: oddly enough no
18:07djvjsstangl: it took a long time to analyze xul.dll
18:07djvjthen eventually spat out numbers
18:07sfinkmccr8: nothing that I know of! I&#39;m asking whether that&#39;s skipping too much.
18:07sstangldjvj: ICs aren&#39;t annotated, so &quot;outside any known module&quot; probably correlates really well to &quot;is IC code&quot;
18:08djvjsstangl: hmm, I&#39;d like to annotate IC code. Can you point me at some examples of existing vtune integration? I&#39;ll add basline IC support for that.
18:08bzsfink: JS_HAZ_GC_CALL JS_HAZ_CAN_RUN_SCRIPT NS_IMETHOD QueryInterface(const nsIID & uuid, void **result) = 0;
18:08bzsfink: Look ok? ;)
18:08sstangldjvj: look at vtune/VTuneWrapper.cpp, it should be pretty obvious
18:08mccr8sfink: I dunno. It is fine with me. :P jonco can look into it if he wants when he gets backed.
18:08sstanglerr js/src/vtune/VTuneWrapper.cpp
18:08sfinkugly as sin, but ok
18:09djvjsstangl: thx
18:09sfinkbz: I&#39;d probably drop the redundant JS_HAZ_GC_CALL though
18:09bzWould you prefer something else?
18:09bzIt&#39;s pretty easy
18:09sstangldjvj: if you&#39;re going to annotate ICs you also have to handle IC code unload events
18:09bzThat&#39;s why I&#39;m asking
18:09sstanglI think ICs aren&#39;t JitCode objects? If they are it&#39;s handled automatically by the JitCode finalizer.
18:09* bz is looking into why his other bits aren&#39;t working right
18:10djvjsstangl: well, the stubcode is certainly JitCode objects.
18:10djvjwe use the same masm in the backend, so it spits out JitCode objs
18:10djvjand we should be able to handle de-registration in destructure I guess
18:10sfinkbz: sadly, it looks like I probably *don&#39;t* get pure virtual decls. But I&#39;d rather have it there, so I&#39;ll take a look to see if I can get it.
18:12ntimsmaug: I don&#39;t see anything suspicious that could explain the issue in the debug build
18:13sfinkdjvj: yeah, I have time to talk today, or tomorrow after 10:30am Pacific time
18:18firebot ASSIGNED, Set an __attribute__ for JS-implemented methods, for static analyses to use
18:19bzsfink: I could also spit this out on the NS_DECL_* macros, but if people hand-write the declaration they might miss it.
18:19bz(and sometimes we do hand-write declarations)
18:19bbouvieranybody willing to steal the remaining review in bug 1346810? (just adding a couple of ReportOOM)
18:19firebot ASSIGNED, Crash [@ js::jit::MBasicBlock::add] with OOM and asm.js
18:20djvjsfink: cool, when is good for you?
18:20djvjsfink: I can do anytime from now until a few hours from now.
18:20sfinkbz: no, this looks great. My gut feel is that it&#39;s better to have separated out.
18:20sfinknow I just need to see if I can make use of it
18:21djvjsstangl: btw, do remember rough numbers for icache misses on your run? I&#39;m getting 7.9% for chrome and 12.3% for us, overall. What was your worload for measuring?
18:22ntimsmaug: we don&#39;t seem to do nested child process for now:
18:22sstangldjvj: Bas was the one who measured
18:22sfinkdjvj: 10 minutes from now?
18:23djvjsfink: sure
18:24bzsfink: ok. Well, let me know?
18:24bzsfink: I see no point in landing this if it doesn&#39;t address your use case, obviously.
18:24sfinkbz: will do. But not immediately.
18:24bzsfink: but I guess I can ask for review now so we handle that in parallel
18:24bzsfink: Sure.
18:25sfinkdjvj: Bas&#39;s stuff is in bug 1330539. I remember he was looking at scrolling something. But in comment 6 ehsan said he got the same thing, using the test case in bug 1326346.
18:25firebot NEW JITted code seems to be causing a lot of icache and ITLB misses
18:25firebot DUPLICATE [Perf][Gslide] 23.22%(2308 ms) slower than Chrome when reading a slide with table content on GSlide
18:25djvjsfink: thanks!
18:27ehsandjvj: yeah, reproduces quite relibaly with that one
18:36sfinkdjvj: your room?
18:40djvjsfink: yeah
18:40djvjsfink: there in a minute.
18:41djvjsfink: k, there.
18:43djvjsfink: hey, i&#39;m in my vidyo room. join whenever.
18:44sfinkdjvj: sorry, my machine has developed a bad habit of hanging, hard, when video conferencing
18:44sfinkyour room is demanding a PIN
18:45djvjsfink: uh..
18:45djvjsfink: taking that off.
18:45djvjsfink: actualy, try 1111
18:56sfinkdjvj: I&#39;m getting no audio from you even through the speakers now
18:56sfinkdo you know if you&#39;re sending?
18:57djvjcheck your input sources
18:57djvjare you on windows?
18:57djvjyou may have to recompile your kernel with AUDIO_DOES_WORK enabled
18:58djvjand -funroll-loops
18:59sfinkdo you have zoom, by any chance?
18:59djvjhaven&#39;t heard of it
18:59djvjhangouts and skype.. yes
19:00djvjyou&#39;re getting super laggy audio from me.
19:00djvjlet&#39;s do skype. kannan.vij
19:03djvjshu: hey, I think this is true, but just wanna confirm.
19:04djvjshu: our JitcodeMap table doesn&#39;t contain any entries that refer to stuff on JS nursery heap right?
19:04djvjIIRC it&#39;s just JSScript*, JitCode*, and some TI-related structures that are pointed to.
19:42bzwhy is my profiler showing calls to BaseProxyHandler::hasOwn from js::ProxyGetProperty?
19:43bzShowing a prototype walk too....
19:43bzI guess it&#39;s confused and the hasOwn is under Proxy::get
19:49shudjvj: outside of jitcoach stuff, no
19:49shudjvj: with jitcoach stuff, we can store a Type that&#39;s pointing to a singleton nursery JSObject, i believe
19:50shujorendorff: ping
19:50jorendorffshu: pong
19:50shujorendorff: wanna chat about compartments?
19:50jorendorffi thought we moved this meeting to next week
19:50jorendorffoh right
19:50shujorendorff: we did?
19:50shujorendorff: we never set one up i don&#39;t think
19:51evilpiebz: inlining
19:51shujorendorff: does next week work better? i can only do monday because of TC39
19:51jorendorffno, i was thinking about the other meeting, the one you and hannes and jan were talking about in email
19:51shujorendorff: ah
19:51shujorendorff: no, that&#39;s a different one
19:51jorendorffshu: right. let&#39;s do this one on monday because I screwed up
19:51jorendorffor tomorrow works
19:51jorendorfftomorrow this time?
19:51shujorendorff: tomorrow&#39;s fine too, i&#39;ll schedule something
19:52shujorendorff: yeah
19:52shuman these new glasses prescriptions really giving me a headache
19:52shumaybe shouldn&#39;t have corrected for astigmatism
20:04mccr8You should adjust to that in a few days.
20:05shuare things going to get magically sharper
20:05mccr8Just less headachey.
21:02shuJohn-Galt: ping
21:08John-Galtshu: Pong-ish
21:08shuJohn-Galt: i wanted a quick and handwavy overview of how PrecompiledScript is used
21:08shuJohn-Galt: is it kept in memory somewhere?
21:09John-Galtshu: Yes, they&#39;re caches on the JS side for up to 5 minutes
21:11* John-Galt -> lunch
21:11* shu looks
21:12shuJohn-Galt: ah, JS side meaning in this jsm
21:12shuJohn-Galt: cool
21:17WaldoYoric: I might end up stealing that refactor-error-reporting-out-of-TokenStream bug from you
21:18Waldothe work I was doing that was going to make use of that, is increasingly coming to depend upon it, if I don&#39;t want to have to add Latin1Char/char16_t parametrizations to stupid things like the bytecode emitter
21:31shujandem: hm, is it known that --no-threads improves code-load
21:31shusomething feels wrong
21:32tcampbellhow is code-load defined
21:33* bz resists the urge to snark
21:34bzabout how it&#39;s 2% up front and 5% when you sell the code.
21:34jandemshu: how much slower are we talking about? could it be related to the tracelogger regression there?
21:34* tcampbell sighs
21:35shutcampbell: i mean the octane benchmark codeload
21:35tcampbellstill unclear what the term means
21:35shutcampbell: there is a benchmark in the octane suite called &quot;code-load&quot;
21:35tcampbellohhh, that makes far more sense
21:36shujandem: let&#39;s see
21:36shujandem: about 6% difference on my machine
21:37shuif only i could figure out how to use perf
21:37shuto look at threads
21:41tcampbell(I get the same result)
21:46shu 17.12% -17.10% [.] 0x0000000000002e90
21:47shuwhy we compressin
21:48tcampbellis this the source code compression stuff?
21:48tcampbellto reduce memory
21:49jandemoh right, that would do it
22:00fitzgenWaldo: ping
22:00Waldofitzgen: pong
22:01fitzgenWaldo: apologies for using you as a C++ encyclopedia, but I tried to search the standard and came up empty handed so...
22:01fitzgenWaldo: can base classes be zero sized inside the derived class?
22:02* bz bets that text is in waldo&#39;s backpack right next to the Constitution.
22:02shuperhaps we should use LZ4 instead of zlib
22:02Waldobz: I have a quick launcher for it, Meta, &quot;C++&quot; pulls up several different C++ specs
22:02Waldofitzgen: base classes can be zero sized, yes
22:02Waldofitzgen: and usually are
22:03fitzgenWaldo: thanks
22:03Waldofitzgen: the exceptions are when the base class appears multiple times in the object through inheritance, and when the first member of the class is itself that base class
22:03Waldoand I might be missing one other, but those are the big&#39;uns
22:03* fitzgen nods
22:03fitzgenWaldo: this is throwing a wrench into bindgen :-/
22:04* bz notes that class A {};
22:04bzclass B : public A {int foo;};
22:04bzint main() {
22:04bz fprintf(stderr, &quot;size: %d\n&quot;, sizeof(B));
22:04Waldodistinct objects are supposed to have distinct addresses, and the base class can&#39;t be zero-sized in those cases because then you could confuse the base class object with the other base class or field
22:04bzanswers that question too.
22:04Waldofitzgen: how so?
22:04fitzgenWaldo: if you want to go down the rabbit hole
22:04crowbotIssue #586: More layout failures when generating SpiderMonkey bindings -
22:05fitzgenbz: I suppose I was essentially staring at that froma different angle, and so was looking for confirmation
22:05Waldouse self::super::super::super::root;
22:06fitzgenWaldo: basically, we can&#39;t support `template<typename T> class Foo : T { ... };` without generating a Rust version for zero sized T and another for non zero sized T
22:07fitzgenWaldo: and also track instantiations
22:07fitzgenWaldo: and also hope that users of the bindings know to check which version they should use
22:08Waldofitzgen: I thought Rust made it so unit structs occupied no space
22:08Waldofitzgen: why can&#39;t the base member in the generated thing be a unit struct?
22:08bzYes, but C++ makes it so a class with no members is 1 byte
22:08bzWhen you poke at it on its own.
22:09bzBut not when it&#39;s a base class.