00:23:16  * bobmcwjoined
00:27:44  * bobmcwquit (Ping timeout: 245 seconds)
01:05:27  * bnoordhuisjoined
01:10:36  * bnoordhuisquit (Ping timeout: 272 seconds)
01:33:31  * enaqxquit (Read error: Connection reset by peer)
01:39:09  * enaqxjoined
02:04:27  * enaqxquit (Read error: Connection reset by peer)
02:07:42  * enaqxjoined
02:18:49  * ysaberiquit (Quit: ysaberi)
02:29:31  * enaqxquit (Remote host closed the connection)
02:32:15  * petka__quit (Quit: Connection closed for inactivity)
03:07:55  * Bob_Gneuquit (Ping timeout: 258 seconds)
03:49:48  * plutoniixquit (Quit: จรลี จรลา)
04:18:42  * caitp-quit (Ping timeout: 256 seconds)
04:26:56  * Bob_Gneujoined
04:49:49  * caitp-joined
04:58:00  * caitp-quit (Ping timeout: 276 seconds)
05:07:50  * caitp-joined
05:44:57  * BobGneujoined
05:45:58  * Bob_Gneuquit (Ping timeout: 256 seconds)
05:48:25  * enaqxjoined
05:57:12  * ofrobotsjoined
07:12:33  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
07:25:43  * plutoniixjoined
07:37:40  * caitp-quit (Ping timeout: 252 seconds)
07:46:41  * caitp-joined
07:53:06  * BobGneuquit (Ping timeout: 258 seconds)
08:23:05  * plutoniixquit (Quit: จรลี จรลา)
08:51:04  * wingoquit (Ping timeout: 245 seconds)
09:05:49  * wingojoined
09:08:09  * caitp-quit (Ping timeout: 245 seconds)
09:40:02  * petka__joined
10:11:20  * bnoordhuisjoined
11:12:21  * caitp-joined
11:15:07  * bnoordhuisquit (Ping timeout: 255 seconds)
11:19:14  * caitp-quit (Ping timeout: 272 seconds)
12:15:59  * caitp-joined
12:20:31  * caitp-quit (Ping timeout: 256 seconds)
13:13:45  * bobmcwjoined
13:26:40  * wingoquit (Ping timeout: 272 seconds)
13:32:18  * caitp-joined
13:33:23  * bobmcwquit (Read error: Connection reset by peer)
13:33:32  * bobmcwjoined
13:33:38  * bobmcwquit (Changing host)
13:33:38  * bobmcwjoined
13:36:57  * caitp-quit (Ping timeout: 264 seconds)
13:54:07  * wingojoined
13:57:02  * bradleymeckjoined
14:09:48  * C-Manjoined
14:30:08  * Bob_Gneujoined
14:30:27  * ofrobotsjoined
14:45:28  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Check" on http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug%20-%203/builds/3106 "V8 Win32 - debug - 3" from 2a6a87d71a1ae280c9a47ec65c75b0cfcf898377: Djordje.Pesic@imgtec.com)
14:56:12  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:10:41  <trungl-bot>Tree opened by machenbach@chromium.org: Tree is open (flake)
15:25:54  * bnoordhuisjoined
15:34:43  * bradleymeckquit (Quit: bradleymeck)
15:55:32  * caitp-joined
15:59:10  * bradleymeckjoined
16:05:13  * edwin_liujoined
16:11:45  * edwin_liuquit (Ping timeout: 240 seconds)
16:18:40  * edwin_liujoined
16:21:16  * edwin_liu_joined
16:23:03  * edwin_liuquit (Ping timeout: 244 seconds)
16:28:25  * edwin_liu_quit (Remote host closed the connection)
16:29:39  * srl295_changed nick to srl295
16:30:44  * ncthom91joined
16:34:20  <ncthom91>hi all. I'm working on a project in which I run separate v8 isolates in separate threads for parallel execution of unrelated scripts. These threads need to communicate back to the main thread, and I could naively do that by passing references to v8 objects created for each isolate, but that's a bad idea right? What's the right way to share a string, for example? Get the underlying char array and memcpy it to a new region of memory,
16:34:20  <ncthom91> and build a new v8 instance from that new region?
16:36:19  <bradleymeck>ncthom91: objects cannot be shared w/ isolates, have a C++ fn exposed to JS that can queue strings to be passed to other isolates
16:37:39  <bradleymeck>the strings will need to be converted to char* yes, you can look at JSON.stringify and String::UTF8Value , you can turn a string into an external string though, but then you need to have some management if you mutate it
16:43:46  <ncthom91>bradleymeck i mean, for example, evaluating a script in a new v8 isolate in a given thread produces a v8 object - let's say a string. And I want that string to be communicated back to the main thread running it's own v8 isolate. So if I try to share it directly, I assume I'm goign to run into GC issues?
16:44:00  <ncthom91>where the earlier isolate cleans up the memory while the second isolate expects teh reference to still be around?
16:44:11  <bradleymeck>ncthom91: I would be surprised if it did not segfault
16:44:28  <ncthom91>so I was thinking the safe way would be convert to char*, memcpy, create a new v8 string instance from the new region of memory
16:44:44  <bradleymeck>sounds fine
16:45:17  <ncthom91>cool. Do I necessarily need the memcpy?
16:45:33  <bradleymeck>for very very large strings you might want to look at External Strings
16:45:43  <bradleymeck>ncthom91: yes unless you use External Strings
16:45:45  * esasjoined
16:46:17  <bradleymeck>it is going to be a bumpy ride
16:46:27  <ncthom91>bradleymeck interesting, I'm unfamiliar with external strings. What exactly are they? Or can you point me to a good resource to learn about it?
16:46:33  <ncthom91>(is this a C++ thing or a v8 thign?)
16:46:59  <bradleymeck>they are v8 thing. basically things not managed by the v8 heap, but point to a piece of memory
16:47:15  <bradleymeck>reading v8.h will give you too much info, lets see if google has a good tut
16:47:37  <ncthom91>that sounds like a perf win for any decently sized string
16:48:33  <caitp->it sounds like it, but...
16:49:24  <bradleymeck>if you externalize a string you get a heap walk T_T
16:50:49  <ncthom91>you mean iterate the whole heap?
16:51:45  <ncthom91>hm yikes this sounds like something I *don't* want to happen frequently lol
16:52:05  <bradleymeck>it needs to be a biiig string
16:52:07  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2009081014])
16:52:21  <ncthom91>my strings will mostly be < 2mb probably
16:52:30  <ncthom91>how big is "biiiig" ?
16:53:10  <bradleymeck>id say 20mb? but it varies for your size of heap, caitp would know more
16:53:26  <ncthom91>ah I don't think I need to worry about strings taht big
16:55:58  <ncthom91>bradleymeck so I suppose I'll probably just use hte char*, memcpy idea. And just to be clear: if I don't explicitly memcpy, as in, instantiate a new v8 object in the other isolate pointing to the same underlying char*, what exactly is the risk?
16:56:10  <ncthom91>that the first isolate will GC the underlying char* while the other expects it to still be there?
16:56:26  <ncthom91>(does each isolate have its own GC?)
16:56:52  <bradleymeck>ncthom91: lets start with, if it is not External you shouldn't be able to get a direct pointer to the memory it is representing
16:57:09  <bradleymeck>yes each isolate has independent GC
17:07:28  * Bob_Gneuquit (Ping timeout: 255 seconds)
17:08:39  * enaqx_joined
17:11:37  * enaqxquit (Ping timeout: 244 seconds)
17:36:29  * ysaberijoined
18:37:21  * caitp-quit (Ping timeout: 256 seconds)
18:39:35  * caitp-joined
18:54:07  * caitp-quit (Ping timeout: 255 seconds)
18:58:18  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Check" on http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20nosnap%20-%20shared/builds/6796 "V8 Win32 - nosnap - shared" from d090469cdd736240f7172696e1f30096695536fc: paul.lind@imgtec.com)
19:33:55  * caitp-joined
19:50:35  * C-Manquit (Quit: Connection reset by beer)
20:16:50  * bradleymeckquit (Quit: bradleymeck)
20:30:12  * ncthom91quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:31:56  * bradleymeckjoined
20:41:45  * bradleymeckquit (Quit: bradleymeck)
20:47:07  * bradleymeckjoined
20:56:07  <trungl-bot>Tree opened by machenbach@chromium.org: Tree is open (flake)
20:59:42  * wingoquit (Ping timeout: 258 seconds)
21:03:00  <bradleymeck>one day Proxy will land and interceptors might be able to intercept Object.defineProperty / freeze /etc.
21:16:16  <caitp>you think Proxy will land?
21:16:23  <caitp>i wouldn't expect that in this quarter or the next :p
21:16:25  <caitp>but maybe..
21:16:36  <bradleymeck>in all honesty I just want the hooks for interceptors
21:16:42  <bradleymeck>idc about JS level proxies
21:18:20  <caitp>i'd be surprised if interceptors aren'tavailable to embedders already, because I'm not sure why else we have them
21:18:44  <bradleymeck>caitp: they are but they don't catch a bunch of things
21:19:05  <bradleymeck>defineProperty is not caught, nor seal preventExtentions
21:19:59  <caitp>what I'm hoping we're going to do, is create a dynamic dispatch mechanism similar to what spidermonkey has, which has something similar to vtables allocated for different internal class types
21:20:36  <caitp>and make it really easy for embedders to deal with, that way
21:20:52  <bradleymeck>would be nice-ish, but vtables are kinda painful
21:21:15  <caitp>wouldn't be a C++-level vtable per se
21:22:02  <caitp>https://github.com/mozilla/gecko-dev/blob/0d950f5c81a0ad6899972aaf85e73e4e56359043/js/public/Class.h#L530 something similarto that
21:22:41  <bradleymeck>i would love that, esp if it could be changed after allocation
21:22:56  <caitp>so you'd have like Value::defineProperty(...) which internally does getClass()->getOps()->defineProperty(...)
21:23:02  <bradleymeck>i assume this would just be for proxies/interceptors?
21:23:52  <bradleymeck>seems like if it was for all objs it would need to add a ton of inlining/ic logic for the ops
21:24:14  <caitp>the big goal of it is just to simplify things, so that instead of every caller having to decide whether to use SetElement() or SetElementWithAccessor() or SetProperty() or SetPropertyWithAccessor() or SetPropertyWithHnadler() or whatever else
21:24:48  <caitp>so, i'm hoping we can do that, but it might be hard to sell
21:25:50  <caitp>at the end of the day though, it should be really easy to make dynamic dispatch work without being super expensive
21:26:46  * bradleymecknods
21:29:27  * bobmcwquit (Remote host closed the connection)
21:31:28  * bradleymeckquit (Ping timeout: 252 seconds)
21:46:00  * ncthom91joined
22:08:41  * bobmcwjoined
22:13:21  * bobmcwquit (Ping timeout: 250 seconds)
22:15:34  * ysaberiquit (Quit: ysaberi)
22:36:31  * RT|Chatzillajoined
23:27:15  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "bot_update" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20presubmit/builds/1051 "V8 Linux - presubmit" from 3a18b9b71bac2f64db3dcbef6e2a503262036c1c: caitpotter88@gmail.com)
23:32:51  * ncthom91quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:41:30  * ncthom91joined
23:42:05  * ncthom91quit (Client Quit)
23:42:53  * ofrobotsjoined
23:51:18  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)