| 00:01:56
| * c4milo | quit (Remote host closed the connection) |
| 01:02:45
| * c4milo | joined |
| 01:16:13
| * iamdustan | joined |
| 02:16:19
| * abraxas | joined |
| 02:31:30
| * leostera | joined |
| 02:38:08
| * stalled | quit (Ping timeout: 260 seconds) |
| 02:47:45
| * stalled | joined |
| 03:01:22
| * scathen^C | joined |
| 03:01:34
| * scathen^C | part |
| 04:19:20
| * jaseemabid | joined |
| 04:50:24
| * Petka | joined |
| 05:25:51
| * c4milo | quit (Remote host closed the connection) |
| 05:48:20
| * jazz264 | joined |
| 05:50:19
| * jaseemabid | quit (Ping timeout: 248 seconds) |
| 07:58:25
| * Lethalman | joined |
| 08:01:56
| * juanjosanchez | joined |
| 08:05:46
| * muelli | joined |
| 08:06:09
| * RT|Chatzilla_ | joined |
| 08:13:03
| * RT|Chatzilla | quit (*.net *.split) |
| 08:39:33
| * ager | joined |
| 09:02:49
| * C-Man | joined |
| 09:22:20
| * Net147 | joined |
| 09:55:01
| * bnoordhuis | joined |
| 10:17:24
| * abraxas | quit (Remote host closed the connection) |
| 10:18:00
| * abraxas | joined |
| 10:22:28
| * abraxas | quit (Ping timeout: 260 seconds) |
| 10:44:09
| * juanjosanchez | quit (Ping timeout: 252 seconds) |
| 11:04:21
| * jazz264 | quit (Ping timeout: 272 seconds) |
| 11:10:28
| * iamdustan | quit (Ping timeout: 240 seconds) |
| 12:19:12
| * xan_ | quit (Quit: leaving) |
| 12:23:53
| * Net147 | quit (Quit: HydraIRC -> http://www.hydrairc.com <- IRC with a difference) |
| 12:25:42
| * juanjosanchez | joined |
| 12:26:43
| * iamdustan | joined |
| 12:50:27
| * c4milo | joined |
| 13:06:30
| * jazz264 | joined |
| 13:08:26
| * c4milo | quit (Remote host closed the connection) |
| 13:08:59
| * c4milo | joined |
| 13:13:31
| * c4milo | quit (Ping timeout: 248 seconds) |
| 13:42:50
| * soluble | joined |
| 13:56:54
| * juanjosanchez | quit (Ping timeout: 256 seconds) |
| 14:05:13
| * bnoordhuis | quit (Ping timeout: 272 seconds) |
| 14:17:17
| * c4milo | joined |
| 14:21:47
| * c4milo | quit (Ping timeout: 248 seconds) |
| 15:10:23
| * bnoordhuis | joined |
| 15:14:48
| * bnoordhuis | quit (Ping timeout: 240 seconds) |
| 15:21:36
| * bnoordhuis | joined |
| 15:43:54
| * soluble | quit (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
| * juanjosanchez | joined |
| 16:31:05
| * jazz264 | quit (Read error: Operation timed out) |
| 16:54:30
| * Lethalman | quit (Remote host closed the connection) |
| 16:57:52
| * juanjosanchez | quit (Quit: Leaving) |
| 16:58:42
| * bnoordhuis | quit (Ping timeout: 252 seconds) |
| 17:24:40
| * bnoordhuis | joined |
| 17:33:06
| * bnoordhuis | quit (Ping timeout: 245 seconds) |
| 17:39:27
| * bnoordhuis | joined |
| 17:57:50
| * bnoordhuis | quit (Ping timeout: 240 seconds) |
| 18:23:11
| * bnoordhuis | joined |
| 18:28:40
| * Lethalman | joined |
| 18:36:21
| * Petka | quit (Quit: L�hd�ss�) |
| 18:57:43
| * futhark1 | joined |
| 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
| * Lethalman | quit (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
| * muelli | quit (Ping timeout: 246 seconds) |
| 21:19:41
| * iamdustan | quit (Ping timeout: 272 seconds) |
| 21:21:33
| * futhark1 | quit (Read error: Connection reset by peer) |
| 22:10:50
| * Vbitz | quit (Ping timeout: 245 seconds) |
| 22:10:53
| * seventh | joined |
| 22:12:51
| * Vbitz | joined |
| 22:14:35
| * wadey | quit (Ping timeout: 245 seconds) |
| 22:17:23
| * wadey | joined |
| 22:23:59
| * RT|Chatzilla | joined |
| 22:53:22
| * leostera | quit (Quit: leostera) |
| 22:53:50
| * iamdustan | joined |
| 22:57:15
| * iamdustan | quit (Remote host closed the connection) |
| 23:06:05
| * c4milo | joined |
| 23:12:26
| * bnoordhuis | quit (Ping timeout: 268 seconds) |
| 23:52:58
| * iamdustan | joined |