00:01:12  * Guest59joined
00:06:05  * Guest59quit (Ping timeout: 268 seconds)
00:29:00  * Guest59joined
01:24:36  * bradleymeckquit (Quit: bradleymeck)
01:34:37  * zvjoined
01:43:05  * bradleymeckjoined
02:20:28  * hferreiroquit (Quit: Connection closed for inactivity)
02:39:45  * xaxxonquit (Ping timeout: 256 seconds)
03:00:32  * xaxxonjoined
03:49:14  * bradleymeckquit (Quit: bradleymeck)
06:35:57  * xaxxonquit (Ping timeout: 240 seconds)
06:38:50  * bradleymeckjoined
06:51:41  * xaxxonjoined
07:12:34  <gsathya>caitp: https://codereview.chromium.org/2497523002/
07:12:51  <gsathya>is the first step
07:13:54  <gsathya>I can't move the symbols without porting PromiseThen and ResolvePromise as it might regress perf
07:14:29  <gsathya>once the promise constructor patch lands, my next patch is to move the symbols along with PromiseThen and ResolvPromise to c++
07:20:08  <caitp>why do you think it will/might regress perf?
07:29:21  <caitp>I think my approach works pretty well, but I may not be able to use the descriptor array due to map private symbols to inobject fields, I think because there are too many inobject fields
07:29:33  * xaxxonquit (Quit: Leaving)
07:38:37  * bradleymeckquit (Read error: Connection reset by peer)
07:46:55  <gsathya>caitp: i was going to have set and get runtime calls to access the inobject properties, which would mean going back to c++ from js. your approach might work without regressions, i'm not too familiar with how DescriptorArray work with symbols. i assume there is still some amount indirection here
07:49:22  <caitp>the type of Name doesn't seem to matter, which is nice, but there are some GC related issues
07:49:55  <caitp>and, some Promise unit tests fail also, but I haven't investigated why, might just be the GC thing again
07:51:09  <caitp>we can eliminate the cost of runtime calls via adding inlining support for them, in js-intrinsic-lowering and ignition (but it may not be worth doing this, since we'll want to get rid of the runtime calls anyways)
07:56:59  <gsathya>yes, agreed about inlining, but that might be too much trouble for now
07:58:13  <gsathya>caitp: how about using GetProperty for now so that you aren't blocked?
08:44:49  * Ultrasaucequit (Ping timeout: 244 seconds)
08:46:16  * Ultrasaucejoined
08:46:41  * hferreirojoined
08:48:39  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Mjsunit" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/7189 "V8 Linux - gc stress" from e3f5c515faa7ec90f044a765a5cd6b3e3be0d90d: hablich@chromium.org)
09:12:53  * bradleymeckjoined
09:30:55  <trungl-bot>Tree opened by hablich@chromium.org: Open
10:12:27  * bradleymeckquit (Ping timeout: 252 seconds)
11:00:01  * xiinotulpjoined
11:03:33  * plutoniixquit (Ping timeout: 248 seconds)
14:16:56  * seventhjoined
14:43:06  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Check" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/12103 "V8 Linux - arm64 - sim - MSAN" from f658e41d864267fb9e99ea76faa7758b0b63d5c9: kozyatinskiy@chromium.org,mlippautz@chromium.org)
15:45:31  <trungl-bot>Tree opened by machenbach@chromium.org: open
16:07:24  * decoderquit (Ping timeout: 252 seconds)
16:08:00  * decoderjoined
16:12:50  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309])
16:37:16  * thefourtheyejoined
17:43:16  * bradleymeckjoined
18:03:38  * bradleymeckquit (Quit: bradleymeck)
18:50:50  <caitp>gsathya: it actually is mostly working now, looks like just a few GC-ish related errors left
18:51:41  <caitp>how have you been running the bluebird benchmarks? I can't apply the v8 patch directly onto node, and replacing deps/v8 in Node with v8 trunk causes huge performance regressions, but it's probably not totally related to the patch
18:53:18  <caitp>not so much gc as heap-verifier, I guess
19:01:45  * jugglinmikejoined
19:02:02  <jugglinmike>aklein: Hey hey--have any time to talk about https://codereview.chromium.org/2009963002/ ?
19:13:42  * seventhquit (Remote host closed the connection)
19:40:28  * hferreiroquit (Quit: Connection closed for inactivity)
19:50:40  * hferreirojoined
19:56:22  * bradleymeckjoined
19:57:45  * bradleymeckquit (Client Quit)
20:04:01  * Cube8joined
20:19:54  <gsathya>caitp: unfortunately the benchmark suite is internal, i can try your patch though
20:20:09  <gsathya>jugglinmike: adam is ooo until monday
20:21:54  <jugglinmike>ah, thanks gsathya!
20:23:13  <gsathya>caitp: does the current patchset work? the benchmark segfaults with your current patch
20:23:49  <caitp>segfault or check failure?
20:24:12  <caitp>there's a check failure in JSPromiseVerify(), but I'm not sure what's causing it yet
20:24:29  <gsathya>segfault
20:24:50  <caitp>interesting, do you have a stacktrace?
20:25:10  <gsathya>does test262 pass?
20:25:16  <gsathya>let me try with debug build
20:26:14  <caitp>haven't tried test262, it passes `make check` on a release build though
20:28:18  <gsathya>debug stacktrace looks useless
20:28:30  <caitp>hmm
20:28:56  <caitp>so it's jitted code segfaulting?
20:29:38  <gsathya>caitp: https://gist.github.com/gsathya/b7249e14ffa2060468ef3bcb0ecaee9c
20:34:38  <caitp>also, is that with --ignition?
20:36:59  <caitp>I don't see ignition in the command line, but the crashes on the CL all seem related to that
20:40:32  <gsathya>caitp: no --ignition
20:41:17  <caitp>alright, well I'll see if I can fix those up
20:41:36  <caitp>it's possible that this is actually slower than just adding runtime calls
20:44:00  <caitp>thanks for taking a look
22:16:09  * Cube8quit (Quit: Leaving)
22:23:41  * Guest59quit (Read error: Connection reset by peer)
22:27:29  * Guest59joined
23:00:21  * RT|Chatzillajoined
23:00:28  * hferreiroquit (Quit: Connection closed for inactivity)
23:01:55  * jugglinmikequit (Ping timeout: 258 seconds)
23:29:39  * rosseauxquit (Excess Flood)
23:30:10  * rosseauxjoined
23:42:28  * thefourtheyequit (Quit: Connection closed for inactivity)