mozilla :: #jsapi

21 Apr 2017
00:14shuWaldo: i've found no reftest or jit-test failures if i don't update the end position on RP
00:14shuWaldo: wanna r?
00:20Waldoshu: this is the | handler.setEndPosition(expr, pos().end);| just before |return handler.parenthesize(expr);| in the |case TOK_LP:| in Parser::primaryExpr? and you just want to remove that single line? r=me to remove, sure
00:20shuWaldo: correct, just flagged in BMO actually
00:31shuWaldo: that calculus book is amazing from the first sentence
00:31shu"considering how many fools can calculate"
00:51Waldoanyone willing to rs= the removal of the unused |static constexpr int32_t TlsSlotOffset = TlsSlotSize;| from WasmBaselineCompile.cpp?
00:52Waldoit's not used, it can't matter, but maybe it's there as some sort of tombstone for something to get back to, or whatever
00:58shuWaldo: looks like it used to be used as a sanity check when the tls slot was pushed onto the stack for debugging purposes or something
00:58shuWaldo: rs=me
00:58Waldofor whatever reason that's showing up as unused in my local builds, but only if I deunify to 1 file per unified build
00:59Waldomaybe something about static globals being checked as unused, only occurs if in the topmost (non-#included) file
00:59Waldoin whichever compiler it is I happen to be compiling with at the moment
02:59Manishearthsfink: is another one
02:59Manishearthit complains we write to nsFont.size
02:59Manishearthwe do, but that nsFont is a field of LangGroupFontSizePrefs
03:00Manishearthunsure how to whitelist that
09:03* Waldo slightly breaks all the parser patches
09:10anbaWaldo: NOOOO!
09:11anbaWaldo: I had hoped to land the destructuring parser changes before the great latin1 tokenstream changes. :-)
09:12Waldoanba: oh, I'm going to be one rolling trainwreck on that front, it's not complete yet, you might get in at a halfway point
09:12Waldoso far I've basically just shoved templates into things
09:12Waldoand in local patching I am *still* just shoving templates into things, almost
09:12anbaWaldo: I've already fished destructuring binding patterns, and now I'm trying to make assignment destructuring syntax-parseable
09:13Waldoonly my very latest patch starts to really make any changes
09:13Waldoand that patch ain't complete yet
09:13Waldocarry on, Mr. Bowditch
09:14Waldothe real fun is going to be when I actually start splitting TokenStream into two parts spattered across the Parser inheritance/template hierarchy, and then |parser->tokenStream| won't actually give you everything it does now
09:14Waldoin other news, Parser and TokenStream as separate things should probably die
09:17anbaWaldo: Maybe I should cc you on the destructuring changes, so you can check if the changes don't clash with your work
09:18Waldoanba: I'll work around/with 'em
09:18Waldoanba: really I am trying not to change logic, and I generally haven't needed to
09:18Waldoanba: the only logic change-ish thing I've done so far, concerns how to treat surrogate-pair parsing
09:19anbaWaldo: Well, that sounds okay for my current work.
09:19Waldoanba: my tree locally has a TokenStream::isMultiUnitCodepoint(T n, uint32_t* code) function added to it, which changes how existing code does it, with an eye to instantiating that separately for T = char16_t and T = unsigned char
09:20WaldoI *think* that type-agnosticish signature will suffice to handle the UTF-8/16 distinction without any deeper change
09:20anbaWaldo: How often did you wish to have if-constexpr for these changes?
09:21Waldooh, and also a TokenStream::appendMultiUnitCodepointToTokenbuf(uint32_t codepoint) function
09:21anbaWaldo: (When I was working on the toUpper/toLower changes, I really did miss to have if-constexpr already available)
09:21Waldoanba: haven't gotten to a point of being really upset about it yet
09:21Waldoanba: the big thing that's made me sad so far, is various lack of support in C++ for partial function template specialization
09:22Waldoanba: so I have |template<> Parser<FullParseHandler, char16_t>::foo() { ... }| when really I want it to be |template<typename CharT> Parser<FullParseHandler, CharT>::foo() { ... }|
09:23Waldobut generally I&#39;m just throwing gobs and gobs of templates and template-dependent inheritance at this so far and haven&#39;t needed anything if-constexpr-like yet
09:23anbaWaldo: hmm, does that mean you needed to copy code to workaround ?
09:23Waldoanba: so in my tree locally I still only have char16_t specializations, nothing for single-byte chars yet
09:23anbaWaldo: ah, I see
09:24Waldoanba: I think I will probably have to have a separate class with static functions in it, and I can spatter ParseHandler and CharT into a class template parameter and a function template parameter, to emulate what partial specialization would give me
09:25Waldoanba: I&#39;m about 90% on this spitballed idea working, but I haven&#39;t started doing it yet
09:54nbpdjvj: tp5n is the top 50, and I already met harald, we had a 1:1 meeting about the JS start-up cache 3 weeks ago.
10:02* Waldo idly waves at nbp
10:02Waldomy schedule has shifted around enough I can&#39;t remember the last time I said hi :-)
10:04nbpWaldo: a month ago?
10:04Waldocould be
10:04nbpWaldo: Are you shiffint schedule to be able to make it for the next JS team meeting?
10:05evilpiejonco: I think you can land the iteratorStart patch now
10:05Waldonah, just happening to be awake now
10:05Waldobut unless the next meeting is a Tuesday morning early again, I imagine I&#39;ll be at it no matter what
10:05WaldoTuesday mornings specifically do not work for me
10:06Waldonor Monday mornings
10:06Waldoany other time would do, tho
10:08nbpWaldo: I can understand I am not a morning person either, especially since I moved back to France.
10:08joncoevilpie: does your patch fix the reason that the first patch got backed out?
10:08Waldonbp: well, the problem for me is Mondays/Tuesdays I have recurring plans in the morning
10:08evilpieJonco: Yeah, I suggest you push to try again though
10:09joncoevilpie: great, was hoping that would be it
10:09joncoevilpie: will do
10:09WaldoI don&#39;t always make a good effort the rest of the time, but I would if there were a meeting requiring it
10:14evilpieCan&#39;t we push the meeting to a later time? I think it was only 4pm in Europe
10:22Waldoon Tuesdays I could be on by 08:00ish or so; on Mondays, closer to somewhat after 09:00
10:23Waldobut I thought the timing was an attempt to be Japan-friendly
11:44Yoricshu: If you still wish to toy with binary ASTs, I have just uploaded a bunch of patches that should make it much easier.
12:31Boneysfink: It seems I may be joining you for the work week in Toronto.
12:31BoneyIs there a wikipedia page or other information about that?
12:31BoneyI&#39;m not yet enrolled into any Mozilla things like e-mail or travel planning though.
12:34jonconaveed: ping
12:34naveedjonco: pong
12:38BoneyHi naveed, I don&#39;t know if we&#39;ve spoken over IRC before. This is Paul Bone.
12:38Boney(so you know my nick)
12:38naveedBoney: well hello!
12:55nbpBoney: Welcome, still awake at this time?
12:58Boneyit&#39;s about 11pm now. I&#39;ll probably go to bed at around 12.
13:06h4writerBoney: welcome!
13:37evilpieshu: time to update test262?
13:42Boneyh4writer: thanks.
14:16tcampbellWhat do AutoEnterOOMUnsafeRegions mean? Are they sanity checks or do we expect them to hit in real code and just take down the browser? I&#39;m getting a try build fail.
14:17Yoricshu: Ok, I have solved the mystery of the shrinking devtools: their code contains lots of comments.
14:18ehoogeveentcampbell: IIUC they&#39;re basically regions that are exempt from our OOM testing, because we can&#39;t reasonably handle allocation failure inside
14:18Yoricshu: djvj: On the other hand, with my latest change, Facebook gzipped size change goes to 99%, so a slight decrease \o/
14:19tcampbellehoogeveen: ah, got it
14:19tcampbellalso, reading some of the bug reports for those intermitents suggests it is an existing problem
14:20tcampbell(the specific job having issues this week that is)
14:22ehoogeveenYeah, from all those pre-existing bugs it sounds like either a big allocation or a really hot site
14:23tcampbellLooks like jonco tracked down to an issue where oomTest creates thousands of compartments in certain cases but we don&#39;t currently trigger GC
14:23ehoogeveenAah yes, I saw that bugmail
14:24evilpieh4writer: what is &quot;rev: warning&quot; on awfy?
14:26joncotcampbell: oh hey, I didn&#39;t see you were talking about that bug
14:26joncotcampbell: yes, it looks like a problem with the oomTest framework
14:26joncotcampbell: it was causing my try runs to fail too :(
14:27tcampbelljonco: thanks. The orange startled me. I thought I&#39;d have to revisit my work
14:28joncoit&#39;s always a pain when you get test failures on windows 7 taskcluster builds only, etc
15:34nbpluke: around?
15:35lukenbp: in videochat, but i&#39;ll ping you in a sec
15:54jorendorffIt just occurred to me that if we were going to implement class/proxy/wrappers in Rust from scratch, we&#39;d use a trait; there&#39;d probably be 1 or 2 fewer indirect jumps / runtime checks each time you hit a proxy/wrapper.
16:04evilpiejorendorff: proxies should just have different JSClasses ...
16:09nbpjorendorff: When did that happen? The debugger?
16:09jorendorffnbp: when did what happen?
16:09nbpjorendorff: re-implementing class/proxy/wrappers
16:10nbpjorendorff: when was the decision took?
16:11ehoogeveenCould be wrong, but I think jorendorff is just musing
16:12jorendorffnbp: we&#39;re not doing that
16:12jorendorffi said &quot;if&quot;
16:12nbpoh, I forgot to read the &quot;if&quot; :(
16:15digitaraldnaveed jandem: can I query smv2 data from awfy?
16:16digitaraldlast data on is Apr 4
16:17h4writer_luke: ping
16:17nbpluke might be around a black hole based on the time a second ticks for him.
16:21lukeh4writer, nbp: pong
16:21h4writer_evilpie: something incorrect. Where did you see it.
16:21nbpluke: Do you have time for a quick review? (Bug 1358521)
16:21firebot NEW, XDROffThreadDecoder fails to decode inner functions (Gecko)
16:21evilpieh4writer_: front page when hovering over a point
16:22lukenbp: yup
16:22nbpluke: thanks :)
16:22h4writer_evilpie: ah, my replacement is not working correctly apparently
16:24lukenbp: ok, i kindof have no idea what&#39;s going on there
16:25lukenbp: i imagine it&#39;s right, i just don&#39;t remember at all how this works
16:25nbpluke: the CompileOption have the ScriptNoRval, but not the inner functions.
16:25nbpluke: which is not the case in the JS shell.
16:26lukenbp: does OwnSource mean top-level?
16:26nbpluke: more-less yes.
16:26lukei vaguely recall that had more of a memory management meaning
16:27lukelike who&#39;s responsible for deleting the source, but that was more of a JSAPI Compile thing, so i might be mixing it up
16:27nbpluke: OwnSource basically means that this is the first JSScript that we are going to encode / decode, which in the case of the XDROffThreadDecoder is always going to be the case.
16:27nbpluke: in other cases hasOption() would be false.
16:28nbpluke: in SM I think we moved to the ScriptSourceObject which is a GC thing.
16:28lukenbp: so there&#39;s no more direct way to say &quot;is the top-level script&quot;?
16:29nbpluke: I think OwnSource is the closest meaning (when we have a source)
16:29lukenbp: what about when we don&#39;t have a source?
16:30nbpluke: then I don&#39;t care.
16:30nbpluke: this is not going to happen in these cases.
16:31nbpluke: MOZ_ASSERT(!!(scriptBits & (1 << OwnSource)) == !sourceObjectArg); and we only provide the sourceObjectArg when we call XDRScript the first time, and it is not passed on.
16:32nbpluke: and we call it on the top-level JSScript, and this only matter for the XDROffThreadDecoder (hasOption())
16:32lukenbp: heh, well, it sounds like you understand what you&#39;re doing then, rs=me
16:35nbpluke: Thanks, I will update the bug with what I commented here, and set the flag.
16:48h4writer_evilpie: should be solved, thanks for letting me know
16:49h4writer_(from now on it should record the correct hash again. Stupid warnings ;))
16:58nbpluke: I commented on the bug, it should hopefully explain better than what I wrote over IRC.
16:59lukenbp: great, thanks
17:05jorendorffSigh, the XDR stuff keeps getting uglier, it seems. Wish I had time to tear it down. :-P
17:16nbpjorendorff: I am trying to convince Yoric to use the new binary format to replace XDR by it.
17:19nbpjorendorff: If you like XDR beauty, have you noticed how easy it was to add the XDRIncrementalEncoder?
17:20* jorendorff looks
17:21nbpstandups: To stick or not to stick, that is Bug 900784 question!
17:21standupsOk, submitted #45055 for
17:21firebot ASSIGNED, [meta] Add start-up cache for any JavaScript code.
17:30tcampbelldjvj: Bug 1358047
17:30firebot ASSIGNED, Move Baseline CacheIR stubcode map from JitCompartment to JitZone
17:46jandembz: ping
17:46bzjandem: ack
17:51jandembz: hm i was wondering about proxy-handler-per-class but i think i remember the problem now - when we nuke a wrapper we&#39;d have to change its class
17:52bzjandem: yes
17:52bzjandem: that sounds about right.
17:52bzjandem: Also, the same thing with TradeGuts bits, right?
17:52bzjandem: or whatever that&#39;s called nowadays
17:53bzthough maybe that already swaps the JSClasses?
17:54jandemi wonder if we couldn&#39;t just give the object a new group and shape when we nuke a CCW
17:54jandemefaust: ^
17:54bzthe other option is that we could rewrite nuking in terms of &quot;update all the references to this thing&quot;
17:54bzso on top of GC tracing stuff or something
17:55bzSo we don&#39;t have to mutate any actual object guts
17:56jandemyeah or we give all wrappers the same handler + class but that will make them even slower
17:58shuYoric: awesome
17:58shuYoric: i can live with size parity
18:06jandembz: i don&#39;t think moving the handler is a blocker for the slot layout bug
18:06jandembz: what if we let the Class specify a number of reserved slots, like for other objects? would that work?
18:11bzjandem: So...
18:12bzjandem: There are two separate issues here, right?
18:12bzjandem: 1) I can&#39;t get arbitrary numbers of slots on a proxy class
18:12bzjandem: 2) There is no sane API that I can use to access slots on both a proxy class and a non-proxy class by slot index
18:13bzjandem: We need to fix #1 no matter what for my purposes.. though maybe we can get away without it if there&#39;s some minimal number of slots we can guarantee on proxies and I make codegen fail if it needs more.
18:13bzjandem: For #2, if we fixed the handler thing the &quot;sane API&quot; could just be js::Get/SetReservedSlot
18:14jandembz: right, so for 1) we could get the number of reserved slots form your proxy class
18:14jandembz: i think for 2) that will work anyway after we do 1), because where native objects have 2 pointers (slots + elements), proxies have ProxyValueArray* + handler
18:14bzjandem: If we don&#39;t fix the handler thing, we need to come up with something akin to Get/SetReservedOrProxyPrivateSlot
18:15bzjandem: Ah, I see
18:15jandemso we could just put n reserved slots after that and then it would look like a native object
18:16bzjandem: hmm
18:16jandemdoes this proxy have its own Class?
18:16bzjandem: all dom proxies have their own classes, yes
18:16bzjandem: So that would not be an issue
18:16jandemok so getting numReservedSlots from the Class would work
18:17bzThis sounds promising. ;)
18:17bz(no pun intended)
18:17jandemyeah I can try something tomorrow/Monday, it doesn&#39;t seem that hard (famous last words and all)
18:17bzAwesome, thank you!
18:18bzIf we can get rid of the Get/SetReservedOrProxyPrivateSlot complexity in the bargain, that would rock
18:18bzSounds like we could
18:19bzproxies would have an unused value in the proxyvaluearray in the dom proxy case, but that&#39;s ok
18:19Yoricshu: Ok, after implementing a smart string table, I am down to 0.95 for Facebook, 0.38 for Devtools.
18:19djvjevilpie: hey, I can steal the r? for bug 1358047 if you and jan are ok with it.
18:19firebot ASSIGNED, Move Baseline CacheIR stubcode map from JitCompartment to JitZone
18:19jandembz: i just wanted to say, we would waste the Value there, but maybe we could get rid of that afterwards
18:19evilpiedjvj: sounds good
18:19jandemdjvj: thanks!
18:20* bz pokes at object layouts
18:20jandembz: so another approach is to rm the ProxyValueArray* pointer, and store ProxyValueArray right after the handler
18:21jandembz: then GetReservedSlot would also just work, because you&#39;d get ProxyValueArray::privateSlot
18:21bzjandem: trying to page in these object layouts
18:22bzso NativeObject and ProxyObject both inherit ShapedObject
18:22Yoricshu: still without regexps or without any information on captured variables.
18:22bzNativeObject then has slots_ and elements_
18:22jandemyeah and proxies have ProxyDataLayout
18:23jandemwhich is also just two pointers
18:23bzand then that&#39;s followed by fixed slots, I guess
18:23bzAre reserved slots guaranteed fixed?
18:23* bz can never recall
18:24bzRight, and a Proxy has a ProxyValueArray*, then a handler
18:25bzI see
18:25bzSo the reason this stuff works right now is that GetReservedOrProxyPrivateSlot pokes at the first fixed slot in the non-proxy case
18:25bzBut pokes at the first &quot;dynamic slot&quot; (aka thing in the ProxyValueArray) in the proxy case
18:26jandembz: yeah and I&#39;m wondering if we could store ProxyValueArray in the first n fixed slots instead of having a pointer to it
18:27djvjjandem: hey, I was thinking about toggleBarriers() in jitcode.
18:27jandembz: then you would have the private/reserved slots at the same location for proxy and native
18:27bzSo the key is that we no longer store the proxyhandler in a slot
18:27djvjwe wrote that code, IIRC, back before we had w^x.
18:27bzI thought we still did
18:27bzGiven that, handler-per-class is not a blocker for slot stuff at all
18:28jandemdjvj: yeah we should reconsider that, maybe measure how often we do the toggling...
18:28jandembz: yes so i think this isn&#39;t too bad. I&#39;m hoping we can store ProxyValueArray inline, that would also save us a dereference
18:28djvjand toggleBarriers() in the presence of w^x is a lot more expensive: a flurry of mprotect() calls before, a huge memory scan across all jitocde (cold and hot), a flurry of mprotect() calls after, and we blow the CPU cache, probably a good chunk of even L3.
18:29bzSo what happens if I ask for more reserved slots than FIXED_SLOTS_MAX ?
18:29bzDo some of them go into dynamic slots?
18:29* bz thought we had code to not do that, but maybe we removed it at some point...
18:29djvjif we did that dynamically, the additional overhead is going to be: 1 read of a constant address which is likely to be in L1, and a single conditional jump off of that read.
18:30jandembz: not sure offhand if we allow it but i think they&#39;d just go in dynamic slots
18:30jandemdjvj: I agree we should try it and see what the overhead is
18:30bzbut in the proxy case what would happen?
18:31bzFwiw, I have no problem adding static asserts that we don&#39;t ask for that many slots
18:31djvjjandem: I&#39;ll make a bug for it. If we can&#39;t find someone I might try it myself.
18:32bzOr just checking that we don&#39;t do it for things that are proxies
18:32jandemdjvj: sounds good, i can also take a look next week
18:32bz&quot;checking&quot; == &quot;at binding codegen time&quot;, so build-time, not runtime
18:33bzjandem: Obviously we&#39;ll need to fix too
18:34jandembz: btw why is GetReservedOrProxyPrivateSlot not sufficient for the bug you mentioned?
18:34bzjandem: and anything else that makes that assumption
18:34bzjandem: Because that only works if the slot index is 0
18:34bzjandem: No?
18:35bz MOZ_ASSERT(slot == 0);
18:35jandembz: ok but ProxyValueArray does have some extra slots after the private slot
18:37bzyes, but those are used for other things already
18:37bze.g. extraSlots[0] is used for the expando object....
18:38jandemso what if we do the following: (1) we get rid of the ProxyValueArray* pointer (we make it always nullptr to catch crashes)
18:38jandem(2) after the handler* pointer, we store n reserved slots
18:38jandem(3) after that, we store ProxyValueArray
18:38jandemhm that would make accessing ProxyValueArray a bit slower i guess
18:39jandemso we could keep the ProxyValueArray* pointer anyway if that&#39;s a problem
18:39jandembut it would still save a malloc
18:39* bz thinks
18:40bzSo for DOM proxies specifically...
18:41bz(and I can&#39;t speak for other proxies, sadly)
18:43bzSorry, was looking up some stuff
18:43bzSo for DOM proxies, we need someplace to put the expando object
18:43bzRight now it goes in extraSlots[0]
18:44bzAnd we need someplace to put the pointer to the C++ object
18:44bzright now it goes in privateSlot
18:44bzAnd we need some places to put some other value.
18:44bzer, values.
18:44bzFor non-proxies, which don&#39;t need an expando object, we ask for (# of some values + 1) reserved slots
18:44bzPut the C++ object in slot 0
18:44bzand the other values in the other reserved slots
18:44jandemhm I&#39;m wondering if we should kill ProxyValueArray completely and use reserved slots for everything
18:45bzwhich may be fixed and may be dynamic
18:45bzWith me so far?
18:45bzSo for the proxy case...
18:46bzThe question is where to put the expando object
18:46bzEverything else we could put in reserved slots just like in the non-proxy case
18:46bzbut probably subject to a constraint where all the reserved slots can be fixed
18:46bzsince there&#39;s nowhere to put dynamic slots, right?
18:47jandemso what if we remove ProxyValueArray, give DOM proxies always 2+ reserved slots, put the c++ object in slot 0, expando in slot 1
18:47bzThen the slot indices for proxies and non-proxies don&#39;t match up
18:47bzfor the &quot;some values&quot;
18:47bzWhich we can deal with, by having branches in the relevant code, etc
18:48bzThe other option is to put expando at the ened
18:48bzer, end
18:48bzBut then code that needs to poke at it, including ICs, has to be told how to find it
18:48bzRight now it just looks in a fixed location...
18:49bzOne kinda-nasty option is that we could put a Heap<JSObject*> where the ProxyValueArray* is right now
18:49bzor some such
18:49bzAnd store the expando there
18:50jandemICs already guard on the shape, which implies the Class, so they could load the expand from a fixed offset right?
18:50bzjandem: they could, if they knew what that offset is
18:51bzjandem: On the DOM side we could probably stash that in our DOMJSClass
18:51bzjandem: on the IC side.. we could add some sort of callback, I guess.
18:51bzjandem: To ask for the info
18:52jandembz: yeah i was just looking at GetDOMProxyExpandoSlot
18:52bzjandem: Fo non-DOM proxies, by the way, prople use both of the extraSlots
18:52bzjandem: oh, right, the expando might not be an object....
18:53bzjandem: It&#39;s really a tristate of &quot;nope&quot;, ExpandoAndGeneration* and JSObject*
18:53bzjandem: currently represented by UndefinedValue, PrivateValue, ObjectValueRespecively
18:53jandembz: ok so storing JSObject* instead of PVA* wouldn&#39;t work
18:53bzjandem: We could do it with null, JSObject*, tagged pointer....
18:54bzjandem: I mean, that&#39;s what a PrivateValue is anyway
18:54bzjandem: The code that pokes at this stuff would need to change to get the uintptr_t or whatever instead of a Value
18:54bzbut it could work
18:54bzCouldn&#39;t be a Heap<JSObject*> though
18:54jandemhaving an optional JSObject* there could be nice for wrappers too i guess..
18:55bzSo a clarification question
18:55bzAre we considering changing the object layout for all proxies?
18:55bzOr just on an opt-in basis?
18:55bzBecause ProxyObject::grayLinkExtraSlot is a thing....
18:55jandemif we want to move ProxyValueArray inline we would have to change all of them i think
18:56jandemwhat does grayLinkExtraSlot do?
18:56bzreturns 1
18:56bzWhich is then used as an arg to GetProxyExtra
18:56bzaka an index into extraSlots in the ProxyValueArray
18:56bzBut this is only used for CCWs that are not DeadProxy
18:57bzSee IsGrayListObject
18:59jandembz: how much do we care about proxy->expando accesses in C++?
18:59jandemi mean perf
19:00jandembecause putting it last might be the simplest option
19:02jandem(you&#39;d have 2 + n reserved slots, 0 is the C++ thing, n-1 is the expando)
19:03bzjandem: sorry, checking
19:05bzjandem: I think checking what its slot index is would not be a problem
19:05bzjandem: perf-wise
19:05bzjandem: So one option is that for non-DOM proxies we leave things as-is
19:06bzjandem: for DOM proxies we do 2+n slots, ensure that fits in max fixed slots, put C++ thing at 0, expando at n-1, others in between
19:06bzjandem: and leave the ProxyValueArray* null
19:06jandemso then the idea is that if the Class wants > 0 reserved slots, we use that instead of ProxyValueArray
19:06jandemyeah that could work
19:07bzjandem: yes
19:07bzjandem: We&#39;ll need to expose or something
19:07bzjandem: via friend api
19:07jandemi still think having these slots inline would be nice for wrappers etc, as the current malloc + dereference is pointless, but at least we could convert incrementally then
19:07bzjandem: So I can do the &quot;ensure fits in fixed slots&quot; bit
19:07bzright, exactly
19:07bzThen we could convert wrappers to the new setup separately
19:08* bz pokes around
19:08jandemok and then we need some sort of callback to call instead of GetDOMProxyExpandoSlot
19:08bzSo we have NativeObject::MAX_FIXED_SLOTS too
19:08jandemthat takes a Class*
19:08bzjandem: yes
19:09bzjandem: So Yet Another Runtime Callback. ;)
19:09bzSo fwiw, I checked how many slots DOM things want right now, at most
19:10bzThe biggest number at the moment is 16
19:10bz(none of these are proxies, of course)
19:10bzThat 16 is 15 &quot;other things&quot; and C++ pointer
19:10jandemif we ever need that many for proxies we could store a slots pointer instead of ProxyValueArray and use dynamic slots
19:10bzFor proxies we could support up to 14 &quot;other things&quot; without going over NativeObject::MAX_FIXED_SLOTS
19:12bzThis sounds pretty good to me, fwiw
19:12bzJust have to update all the bits in sync. ;)
19:12bzCodeGenerator::visitGetDOMProperty won&#39;t need changes
19:12jandemyeah it&#39;s pretty nice
19:13bzNor will visitGetDOMMemberV/visitGetDOMMemberT
19:13* bz wonders where we enforce that the &quot;DOM member&quot; case is in fact a fixed slot...
19:13jandembz: just curious, how many of these 14 slots are you going to use on DOM proxies?
19:13bzjandem: well, at the moment we use 0... ;)
19:15bzjandem: Basically, we&#39;ll end up using them as we add [Cached] or [StoreInSlot] things to DOM proxies
19:15bzIn practice, I doubt it will ever be more than 2-3
19:15tcampbellevilpie: ah, one difference between HasOwn and In is that |in| can throw
19:15bzRight now the only thing using 14 slots is Navigator
19:15bzand some of our test interfaces
19:15jandemheh, Navigator
19:16bzI mean 14 not counting the C++ object pointer
19:16bzAnd before that...
19:16evilpietcampbell: hasOwnProperty can throw as well, i.e., &quot;&quot;)
19:16bzWorkerNavigator uses 7 plus C++ pointer
19:17bzWindow uses 3 + C++ pointer
19:17bzEverything else uses less
19:17tcampbellevilpie: doesn&#39;t throw for me =S
19:17bzone sec
19:18bzI lie
19:18bzBecause these asserts are not how I thought they were
19:18bzone sec
19:19bzthose are indices
19:19bzSo add 1 to everything
19:19tcampbellevilpie: ah. was not aware of the difference with .call
19:19bzSo window has 4 + C++ pointer
19:20jandemok makes sense
19:20bzIn any case, most things don&#39;t have 14. ;)
19:20jandembz: I just realized for the non-DOM proxies we could still store ProxyValueArray in fixed slots, as long as we keep the ProxyValueArray* pointer in place (almost) nobody cares, and then we can still get an easy perf win from that
19:20bzjandem: oh, indeed!
19:21bzjandem: Though we could also just work on getting rid of it, then, since the extra pointer-chase is silly
19:21jandembz: yeah agreed
19:21bzyeah, so
19:21bzCodeGenerator::visitGetDOMMemberV/T assume the slot is fixed
19:22* bz tries to figure out why that&#39;s ok to assume
19:22jandemthis would make proxies more like native objects in terms of slots, pretty sweet
19:24jandembz: i have to run soon. I can make the JS changes for this, i guess we can land that first and then convert the DOM proxies
19:24jandemjust need to add a test proxy class with reserved slots to the shell
19:24jandembut we&#39;d want that anyway
19:24bzjandem: Right, so we can do this in two steps
19:24bzjandem: land the generic infra
19:25bzjandem: Then conver the DOM proxies and the corresponding jit bits
19:25bzwe used to have a thing!
19:25bzasserting that we fit in fixed slots
19:26* bz looks into what happened to it
19:26bzSomeone removed it. :(
19:27jandembz: I gtg, please update the bug if this plan doesn&#39;t work for some reason so i don&#39;t waste time on it :)
19:29bzjandem: the thing I&#39;m looking into is not relevant to this plan
19:29bzjandem: Just someone removing a static_assert that doesn&#39;t seem ok to remove, so looking into why
19:33evilpiewait nbp is away again?
19:39bzIt was removed without review
20:20Manishearthsfink: any luck with the nsIAtom stuff?
20:23jimbWhat does a call to ReportErrorToGlobal do, in practical terms, in the browser?
20:29bzjimb: depends on the global
20:29bzjimb: but in general, it would fire error events, log to console, etc
20:29jimbbz: okay, thanks
20:30bzjimb: Arguably, for the use cases we have for it, firing error events is not desired...
20:30bzjimb: Luckily, the debugger case has a comment explaining why it&#39;s not a problem in that case...
20:31bzjimb: and in the Promise case the thing involved is not a web page, pretty much by definition.
20:32jimbI feel like there should be a special place in hell for people who eat errors, but then there are cases where you have a very generic API that can&#39;t report anything beyond, &quot;That didn&#39;t work.&quot;
20:33jimbSo ReportErrorToGlobal is probably better than eating things, but only a little better.
20:33bzjimb: right
20:33bzjimb: In that it reports to the browser console or whatnot
20:33jimbwhich I guess is the best one can do
20:33bzjimb: It _does_ report the value you passed it
20:33bzjimb: so that can have a stack and message and whatnot....
20:56Yoricshu: If you want to toy with it, I have uploaded my final version of the week.
20:57shuYoric: thanks
21:43Waldobz, jimb: would either of you happen to know just how the browser/debugger consume the flags field in JSErrorReport, and exactly how much they depend on its exact value, beyond whether it contains JSREPORT_ERROR or JSREPORT_WARNING, and whether JSREPORT_STRICT in flags is treated specially?
21:44jimbWaldo: I have no idea!
21:46jimbWaldo: I feel like I was just asked: Would you happen to know if the eldest uncle of that guy across the street has ever privately regretted entering the astronaut training program?
21:46Waldothe answer to that question is no, obvs
21:50* Waldo decides this is a question he can&#39;t afford to use the answer to right now, anyway, as a matter of risks and rewards
21:52bz_awayWaldo: Pretty sure the browser just does bit tests on that thing, and does it against symbolic names
21:53bz_awaywaldo: Ah, I lie. I guess there&#39;s
21:53bz_awaywaldo: why that&#39;s there I dunno yet
21:53* bz_away away for real
22:09shuevilpie: missed your test262 msg earlier: i&#39;m holding off to have Bocoup do an update for them to see what the process is
22:09shuevilpie: next week
22:34Waldomrgiggles: pun
22:34mrgigglesWaldo: Atoms are untrustworthy.
22:34mrgigglesWaldo: They make up everything.
22:44shuthese 2-parter puns
22:48Manishearthsfink: fwiw I also added because we call some other things there
22:50sfinkManishearth: wfm. Is there anything automatable? I mean, the analysis could know that you&#39;re holding a lock there, but I guess it can&#39;t know exactly what that lock might be protecting.
22:51Manishearthsfink: lock should turn off the analysis imo
22:51Manishearthor, particularly annotated locks
23:50Manishearthsfink: check out
23:50ManishearthI included your placement new fix and it&#39;s complaining on more functions
23:50Manishearthmy changes only whitelisted things
23:51Manishearthactually wait
23:52Manishearthyeah, no, it&#39;s breaking because of nsStyleGradient* result = new nsStyleGradient();
23:52Manishearthand stuff like that
23:53ManishearthI&#39;m going to revert that commit for now since it&#39;s not necessary for that bug anyway
23:55vladandoes SpiderMonkey &quot;re-lazify&quot; functions that are not likely to be executed again?
23:55vladanmicrosoft&#39;s blog post:
23:57vladansfink: cool, thanks
22 Apr 2017
No messages
Last message: 155 days and 3 hours ago