00:01:56  * c4miloquit (Remote host closed the connection)
01:02:45  * c4milojoined
01:16:13  * iamdustanjoined
02:16:19  * abraxasjoined
02:31:30  * leosterajoined
02:38:08  * stalledquit (Ping timeout: 260 seconds)
02:47:45  * stalledjoined
03:01:22  * scathen^Cjoined
03:01:34  * scathen^Cpart
04:19:20  * jaseemabidjoined
04:50:24  * Petkajoined
05:25:51  * c4miloquit (Remote host closed the connection)
05:48:20  * jazz264joined
05:50:19  * jaseemabidquit (Ping timeout: 248 seconds)
07:58:25  * Lethalmanjoined
08:01:56  * juanjosanchezjoined
08:05:46  * muellijoined
08:06:09  * RT|Chatzilla_joined
08:13:03  * RT|Chatzillaquit (*.net *.split)
08:39:33  * agerjoined
09:02:49  * C-Manjoined
09:22:20  * Net147joined
09:55:01  * bnoordhuisjoined
10:17:24  * abraxasquit (Remote host closed the connection)
10:18:00  * abraxasjoined
10:22:28  * abraxasquit (Ping timeout: 260 seconds)
10:44:09  * juanjosanchezquit (Ping timeout: 252 seconds)
11:04:21  * jazz264quit (Ping timeout: 272 seconds)
11:10:28  * iamdustanquit (Ping timeout: 240 seconds)
12:19:12  * xan_quit (Quit: leaving)
12:23:53  * Net147quit (Quit: HydraIRC -> http://www.hydrairc.com <- IRC with a difference)
12:25:42  * juanjosanchezjoined
12:26:43  * iamdustanjoined
12:50:27  * c4milojoined
13:06:30  * jazz264joined
13:08:26  * c4miloquit (Remote host closed the connection)
13:08:59  * c4milojoined
13:13:31  * c4miloquit (Ping timeout: 248 seconds)
13:42:50  * solublejoined
13:56:54  * juanjosanchezquit (Ping timeout: 256 seconds)
14:05:13  * bnoordhuisquit (Ping timeout: 272 seconds)
14:17:17  * c4milojoined
14:21:47  * c4miloquit (Ping timeout: 248 seconds)
15:10:23  * bnoordhuisjoined
15:14:48  * bnoordhuisquit (Ping timeout: 240 seconds)
15:21:36  * bnoordhuisjoined
15:43:54  * solublequit (Ping timeout: 252 seconds)
16:06:39  * RT|Chatzilla_quit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2009081014])
16:29:15  * juanjosanchezjoined
16:31:05  * jazz264quit (Read error: Operation timed out)
16:54:30  * Lethalmanquit (Remote host closed the connection)
16:57:52  * juanjosanchezquit (Quit: Leaving)
16:58:42  * bnoordhuisquit (Ping timeout: 252 seconds)
17:24:40  * bnoordhuisjoined
17:33:06  * bnoordhuisquit (Ping timeout: 245 seconds)
17:39:27  * bnoordhuisjoined
17:57:50  * bnoordhuisquit (Ping timeout: 240 seconds)
18:23:11  * bnoordhuisjoined
18:28:40  * Lethalmanjoined
18:36:21  * Petkaquit (Quit: L�hd�ss�)
18:57:43  * futhark1joined
19:15:01  <futhark1>hi, anyone here who knows about v8 strings, strings between v8 <-> blink, and garbage collection who can explain slowness in: https://code.google.com/p/chromium/issues/attachmentText?id=305037&aid=3050370002000&name=gc.html&token=YZwhDIn5bgkUwL7r3qXLNdCvdB4%3A1381950682339 ?
19:19:19  <bnoordhuis>futhark1: broken link? what's the issue #?
19:19:47  <futhark1>305037
19:19:58  <futhark1>bnoordhuis: gc.html attachment
19:21:23  <bnoordhuis>futhark1: right, i see it.
19:21:40  <bnoordhuis>don't know what would be causing that. maybe the repeated flattening of the `str` cons string
19:22:57  <bnoordhuis>the first one, oneMillionChars, should really have an impact though unless you have a constrained heap
19:23:03  <bnoordhuis>*shouldn't
19:23:45  <futhark1>bnoordhuis: I'm working in blink and don't have much knowledge about ecmascript engine details.
19:24:05  <futhark1>bnoordhuis: I ran about:tracing
19:24:39  <futhark1>bnoordhuis: long lasting garbage collections during the latter loop.
19:25:12  <bnoordhuis>futhark1: when you do s += s, v8 creates an object that looks like { left: "...", right: "..." }
19:25:31  <bnoordhuis>it's called a cons string and you can build trees of them
19:26:05  <bnoordhuis>but eventually you need to flatten the tree. that's when you alloc memory, walk the tree and copy the fragments out
19:26:29  <bnoordhuis>if you're repeatedly flattening it, that's going to cost
19:26:39  <futhark1>ok
19:26:44  <bnoordhuis>used to be something of an issue in node.js
19:27:45  <bnoordhuis>we worked around that by caching the flattened string on the c++ side
19:28:09  <futhark1>bnoordhuis: since the second part is not related to the oneMillionChars thing, you're saying that creating the strings in the second part could cause flattening of the tree built by the oneMillionChars thing?
19:28:39  <bnoordhuis>futhark1: no, i was saying that i don't see how the oneMillionChars thing affects what comes after it :)
19:29:16  <bnoordhuis>futhark1: the only semi-plausible reason i can think of is heap pressure
19:29:23  <futhark1>bnoordhuis: no exactly. unless there is some heap constraint that indirectly causes flattening
19:29:25  <futhark1>right
19:30:07  <bnoordhuis>i don't think v8 actually does implicit flattening, only on demand
19:30:18  <bnoordhuis>but oneMillionChars is a tree of one million cons strings
19:30:36  <bnoordhuis>later on, you're repeatedly flattening the other cons string
19:30:43  <bnoordhuis>which requires v8 to allocate heap memory
19:30:59  <bnoordhuis>which in turn will make it run the garbage collector a lot
19:31:00  <futhark1>bnoordhuis: but wait. interesting part is that it's the createTextNode loop that is slow.
19:31:08  <bnoordhuis>which then has to traverse that one million cons string objects
19:31:38  <futhark1>the str += str is actually not slow.
19:31:52  <bnoordhuis>no, but the createTextNode thing is, right?
19:31:54  <futhark1>If I just comment out the createTextNode call, it's faster.
19:32:13  <bnoordhuis>right. because createTextNode undoubtedly has to flatten the string
19:32:15  <futhark1>If I call createElement instead, it's the same perf issue
19:32:36  <futhark1>so I thought it might be some v8 -> blink string translation
19:32:36  <bnoordhuis>if createTextNode does something like String::Utf8Value s(arg[0]), that'll flatten it
19:33:29  <futhark1>bnoordhuis: so the funny thing is that still that oneMillionChars should not affect flattening of str
19:33:52  <bnoordhuis>well, it would if the gc has to traverse all those cons strings
19:34:09  <bnoordhuis>but... the var is nulled so it should be reclaimable on the first gc run
19:34:22  <bnoordhuis>maybe run with --trace_gc --trace_gc_verbose to see what's happening :)
19:35:35  <futhark1>bnoordhuis: thanks for your help. I'll try that. I don't expect to be able to fix it myself, though.
19:41:23  <muelli>Hm. Weird. I see ConsStrings but I don't see where they are coming from. I.e. I printf on AllocateConsString but I don't see the creation of the ConsString I see later. Is there another place for ConsStrings to be created?
19:42:19  * Lethalmanquit (Read error: Connection reset by peer)
19:51:25  <bnoordhuis>muelli: the generated code can allocate cons strings inline
19:51:36  <muelli>ah! Damn.
19:51:51  <muelli>hm. But I could turn that off, right?
19:52:41  <bnoordhuis>hm, don't think there's a switch for that
19:53:14  <bnoordhuis>fwiw, it's the StringAddStub code in src/code-stubs-*
19:55:33  <muelli>hm. interesting. My version is apparently too old. I think I found the place though.
20:01:29  <futhark1>bnoordhuis: I did run with --trace-gc --trace-gc-verbose but I don't know what to look for.
20:02:28  <futhark1>bnoordhuis: should I mark the issue with a label for v8?
20:03:18  <bnoordhuis>futhark1: i don't know. i suspect it's not really a v8 issue but...
20:03:40  <futhark1>ok
20:03:42  <bnoordhuis>what did --trace-gc etc. print?
20:05:19  <muelli>hm. I see AllocateTwoByteConsString(rcx, rdi, no_reg, &call_runtime) and AllocateTwoByteConsString(rcx, rdi, no_reg, &runtime). I wonder whether "runtime" or "call_runtime" refer to the code in runtime.cc...
20:06:32  <futhark1>bnoordhuis: well. various used/available memory data. As I said, I wouldn't know what to look for. It did say "allocation failure", but then again that was also the case when loading some arbitrary news site.
20:08:57  <bnoordhuis>muelli: it does
20:09:25  <bnoordhuis>futhark1: yeah, v8's gc is lazy. it doesn't start scanning until it has to (somewhat simplified)
20:09:41  <muelli>bnoordhuis: hm. So I could replace AllocateTwoByteConsString(rcx, rdi, no_reg, &runtime) with AllocateTwoByteConsString(rcx, rdi, no_reg, &call_runtime)? Or the other way around?
20:10:47  <bnoordhuis>muelli: you mean change the label from runtime to call_runtime or vice versa?
20:11:20  <muelli>bnoordhuis: yes. My question is whether this would be sufficient to not call the generated code, but the stuff in runtime.cc
20:13:20  <bnoordhuis>muelli: depends on what the code behind the label does. a label is basically a jump in the generated code to some other generated code
20:16:19  <muelli>hm. yeah. well. it's way too late now for me. I'm coming back tomorrow. gn8 guys.
20:20:26  <bnoordhuis>sleep tight :)
21:18:19  * muelliquit (Ping timeout: 246 seconds)
21:19:41  * iamdustanquit (Ping timeout: 272 seconds)
21:21:33  * futhark1quit (Read error: Connection reset by peer)
22:10:50  * Vbitzquit (Ping timeout: 245 seconds)
22:10:53  * seventhjoined
22:12:51  * Vbitzjoined
22:14:35  * wadeyquit (Ping timeout: 245 seconds)
22:17:23  * wadeyjoined
22:23:59  * RT|Chatzillajoined
22:53:22  * leosteraquit (Quit: leostera)
22:53:50  * iamdustanjoined
22:57:15  * iamdustanquit (Remote host closed the connection)
23:06:05  * c4milojoined
23:12:26  * bnoordhuisquit (Ping timeout: 268 seconds)
23:52:58  * iamdustanjoined