00:10:29  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
00:12:03  * Guest59joined
00:28:21  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
00:29:04  * Guest59joined
02:00:29  * hferreiroquit (Quit: Connection closed for inactivity)
02:11:14  * plutoniixjoined
02:11:16  * plutoniixquit (Max SendQ exceeded)
02:17:30  * decoderquit (Ping timeout: 256 seconds)
02:19:18  * decoderjoined
03:22:04  * xaxxonjoined
03:48:28  * xaxxonquit (Quit: Leaving)
05:13:56  * plutoniixjoined
07:08:40  * BobGneujoined
07:58:08  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Mjsunit" on http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/9474 "V8 Linux64 GC Stress - custom snapshot" from 1e3c5c90cdb1d2b2e5a950d72cb509cfc341e374: jgruber@chromium.org)
08:16:55  * hferreirojoined
08:36:24  <trungl-bot>Tree opened by machenbach@chromium.org: open
09:38:57  * plutoniixquit (Ping timeout: 240 seconds)
09:47:51  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Check,Check - extra" on http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/12915 "V8 Linux64 TSAN" from fa2fdf275197185d9bca9d5e72c16a60722c3893: ahaas@chromium.org,hpayer@chromium.org,jgruber@chromium.org,mstarzinger@chromium.org)
09:48:19  * plutoniixjoined
09:50:52  <trungl-bot>Tree closed by machenbach@chromium.org: closed - tsan fa2fdf275197 ? - waiting for bisect
10:05:59  <trungl-bot>Tree opened by machenbach@chromium.org: open
10:29:52  <ebarrett>caitp: here?
10:33:24  <ebarrett>i was wondering where you read about the v8 versions?
10:35:01  <ebarrett>perhaps in sync with chrome?
10:35:04  <ebarrett>https://www.chromium.org/developers/calendar
10:39:42  <ebarrett>caitp: this page says 5.4 is stable: https://omahaproxy.appspot.com/
10:40:59  <ebarrett>5.5 is beta
10:42:41  * plutoniixquit (Quit: Leaving)
10:49:17  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "compile" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14886 "V8 Linux - shared" from 1852300954c216c29cf93444430681d213e87925: leszeks@chromium.org)
10:52:17  <trungl-bot>Tree opened by machenbach@chromium.org: open
11:15:38  <caitp>ebarrett: 5.5 will be branched to stable in the next week
11:16:49  <ebarrett>ok
11:38:02  * BobGneuquit (Read error: Connection reset by peer)
13:40:19  * plutoniixjoined
14:03:27  * bobmcwjoined
14:21:57  * sxaquit (Ping timeout: 244 seconds)
14:47:39  * sxajoined
16:17:57  <caitp>anba is at it again
16:18:50  * bradleymeckjoined
16:23:06  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
16:25:07  * bradleymeckquit (Quit: bradleymeck)
16:56:46  * seventhjoined
17:01:23  * xaxxonjoined
17:27:13  <gsathya>caitp: the ispromise function installation code in boostrapper sets up the formal_parameter_count
17:27:59  <gsathya>(re: using kDontAdaptArgumentsSentinel)
17:28:18  <caitp>I remember seeing a comment from Benedikt saying it was "redundant and wrong", though
17:28:39  <caitp>maybe that was just for a stub
17:28:40  <caitp>dunno
17:46:37  <caitp>gsathya: anba's 2 bugs re: promises and async functions are the result of invalid optimizations in our code :\
17:46:49  <caitp>and I've just noticed that we have some weird observable behaviour that shouldn't be observable
17:58:15  <gsathya>caitp: i don't think your comment#6 is non-compliance. Promise.resolve(p) should return p
17:58:32  <caitp>I erased comment #6
17:58:36  <gsathya>PromiseCastResolved is busted, we need a check for PromiseThen
17:58:52  <gsathya>oh sorry
17:59:00  <caitp>the get should be observable, you're right
17:59:10  <caitp>but, we can't skip the enqueue promise job for builtin promises, unfortunately
17:59:35  <caitp>we might be able to do a special promise job that doesn't call handler functions
18:15:10  <gsathya>caitp: ugh, yes
18:15:28  <caitp>I'm not sure it's worth having a separate path for builtin promises though
18:16:33  <gsathya>it definitely is, we skip the runtime call to enqueue and a tick
18:17:25  <caitp>well, not enqueueing the task is an observable spec violation, even though most people wouldn't notice
18:18:37  <gsathya>well, according to the spec we should resolve in two ticks(one tick for enqueue, one tick for fulfill), but we do it in one, so it isn't noticeable
18:18:54  <caitp>but it is noticeable based on anba's bug
18:18:55  <gsathya>but this is super special cased for resolving against builtin promises that are already resolved .. which isn't all that common
18:18:57  <caitp>it's definitely hard to notice
18:19:07  <caitp>but it's clearly observable
18:19:15  <caitp>it affects the ordering of other promises
18:19:25  <caitp>or, ordering of other promise tasks
18:19:36  <gsathya>yes, it is observable now with async await
18:26:14  * bradleymeckjoined
18:26:42  <gsathya>caitp: https://bugs.chromium.org/p/v8/issues/detail?id=5691 ah
18:28:04  * bradleymeckquit (Client Quit)
18:28:22  <caitp>yeah, it's observable without async
18:28:28  <gsathya>:(
18:34:17  <caitp>it's weird to require microtasks ticks for Promise.resolve() though, maybe there's an argument to be made to change the spec
18:34:23  <caitp>er, require 2 microtasks*
18:42:32  * thefourtheyequit (Quit: Connection closed for inactivity)
19:01:29  * xiinotulpjoined
19:04:56  * plutoniixquit (Ping timeout: 250 seconds)
19:32:11  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
19:34:18  * Guest59joined
20:10:19  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
20:55:12  * seventhquit (Quit: ...)
21:00:42  * bradleymeckjoined
21:04:45  * Guest59joined
21:06:37  * sxaquit (Ping timeout: 260 seconds)
21:06:45  * sxajoined
21:20:06  * rwlbuisquit (Quit: Connection closed for inactivity)
22:28:46  * bradleymeckquit (Quit: bradleymeck)
22:31:47  * bradleymeckjoined
22:45:55  * RT|Chatzillajoined
22:57:48  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:01:00  * Guest59joined
23:13:14  * bradleymeckquit (Quit: bradleymeck)
23:32:19  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:32:43  <gsathya>caitp: did you figure out reason for the GC crash with your promise inobject prop CL?
23:35:04  * Guest59joined
23:37:26  * bradleymeckjoined
23:39:26  * bradleymeckquit (Client Quit)
23:40:53  * xiinotulpquit (Quit: Leaving)
23:44:37  <caitp>gsathya: like igor said, it fails if the object goes into slow mode
23:45:00  <caitp>i thought the fields before header size would stay fast, but nope
23:45:35  <caitp>i think that is fixable
23:45:46  <caitp>but maybe not worth it
23:46:45  <xaxxon>any general guidelines about how to make the process of going back and forth between javascript and c++ fast? like when you call a native function? like maybe something that the debug javascript library does?
23:47:07  <xaxxon>is that special @ syntax anything special?
23:48:45  <xaxxon>from a performance perspective?
23:57:05  <caitp>xaxxon: the thing is, you have entry/exit frames, can't inline (you could add inlining support if you needed to downstream, but not automatic), bunch of other things
23:59:08  <caitp>v8 intrinsics still need entry/exit frames, and generally aren't handled specially by optimizing backends (but can be, ditto for ignition)
23:59:16  <xaxxon>ahh
23:59:56  <xaxxon>just figured I'd ask. I very poorly implemented an interface thinking that doing stuff in c++ would be good. I understand better now, but it's sort of too late